Teknikestro Skyeng Kirill Rogovoy () faras prezenton ĉe konferencoj en kiuj li parolas pri la kapabloj, kiujn ĉiu bona programisto devus disvolvi por iĝi la plej bona. Mi petis lin dividi ĉi tiun rakonton kun legantoj de Habra, mi donas la parolon al Kirill.
La mito pri bona programisto estas, ke li:
- Skribas puran kodon
- Konas multajn teknologiojn
- Kodigo de taskoj pli rapide
- Konas amason da algoritmoj kaj dezajnaj ŝablonoj
- Povas refaktori ajnan kodon uzante Puran Kodon
- Ne perdas tempon por neprogramaj taskoj
- 100% mastro de via plej ŝatata teknologio
Jen kiel HR vidas idealajn kandidatojn, kaj vakantaĵoj, sekve, ankaŭ aspektas tiel.
Sed mia sperto diras, ke tio ne estas tre vera.
Unue, du gravaj malgarantioj:
1) mia sperto estas produktteamoj, t.e. kompanioj kun propra produkto, ne subkontraktado; en subkontraktado ĉio povas esti tre malsama;
2) se vi estas juna, tiam ne ĉiuj konsiloj estos aplikeblaj, kaj se mi estus vi, mi koncentriĝus pri programado nuntempe.
Bona programisto: realeco
1: Pli bona ol averaĝa kodo
Bona programisto scias kiel krei bonegan arkitekturon, skribi bonegan kodon kaj ne fari tro da cimoj; Ĝenerale, li faras pli bone ol averaĝe, sed li ne estas en la supra 1% de specialistoj. La plej multaj el la plej bonegaj programistoj, kiujn mi konas, ne estas tiel bonegaj kodistoj: ili estas bonegaj pri tio, kion ili faras, sed ili ne povas fari ion supereksterordinaran.
2: Solvas problemojn prefere ol krei ilin
Ni imagu, ke ni devas integri eksteran servon en la projekton. Ni ricevas la teknikajn specifojn, rigardas la dokumentaron, vidas, ke io estas malaktuala tie, komprenas, ke ni devas pasi pliajn parametrojn, fari iujn ĝustigojn, klopodi ĉion iel efektivigi kaj igi iun kurban metodon ĝuste funkcii, fine, post kelkaj paro. de tagoj ni komprenas, ke ni ne povas daŭrigi tiel. La norma konduto de programisto en ĉi tiu situacio estas reveni al komerco kaj diri: "Mi faris tion kaj tion, ĉi tiu ne funkcias tiel, kaj tiu tute ne funkcias, do iru mem eltrovi ĝin. ” Komerco havas problemon: vi devas enprofundiĝi en kio okazis, komuniki kun iu, kaj provi iel solvi ĝin. La rompita telefono komenciĝas: "Vi diru al li, mi tekstos al ŝi, rigardu, kion ili respondis."
Bona programisto, alfrontita kun tia situacio, mem trovos kontaktojn, kontaktos lin per telefono, diskutos la problemon, kaj se nenio funkcias, li kolektos la ĝustajn homojn, klarigos ĉion kaj proponos alternativojn (plej verŝajne, estas alia. ekstera servo kun pli bona subteno). Tia programisto vidas komercan problemon kaj solvas ĝin. Lia tasko estas fermita kiam li solvas komercan problemon, kaj ne kiam li renkontas ion.
3: Provas elspezi minimuman penon por akiri maksimumajn rezultojn, eĉ se tio signifas skribi lambastonojn
Disvolviĝo de programaro en produktaj kompanioj preskaŭ ĉiam estas la plej granda elspezo: programistoj estas multekostaj. Kaj bona programisto komprenas, ke komerco volas akiri la maksimuman monsumon elspezante la minimumon. Por helpi lin, bona programisto volas elspezi la minimuman kvanton de sia multekosta tempo por akiri la maksimuman profiton por la dunganto.
Estas du ekstremoj ĉi tie. Unu estas, ke oni povas ĝenerale solvi ĉiujn problemojn per lambastono, sen ĝeni arkitekturon, sen refaktorado ktp. Ni ĉiuj scias kiel ĉi tio kutime finiĝas: nenio funkcias, ni reverkas la projekton de nulo. Alia estas kiam persono provas elpensi idealan arkitekturon por ĉiu butono, pasigante horon por la tasko kaj kvar por refactoring. La rezulto de tia laboro aspektas bonega, sed la problemo estas, ke en la komerca flanko necesas dek horoj por kompletigi butonon, en ambaŭ la unua kaj dua kazoj, simple pro malsamaj kialoj.
Bona programisto scias kiel ekvilibrigi ĉi tiujn ekstremojn. Li komprenas la kuntekston kaj faras la optimuman decidon: en ĉi tiu problemo mi tranĉos lambastonon, ĉar ĉi tio estas kodo, kiun oni tuŝas unufoje ĉiujn ses monatojn. Sed en ĉi tiu, mi ĝenos kaj faros ĉion kiel eble plej ĝuste, ĉar cent novaj funkcioj, kiuj ankoraŭ devas esti evoluigitaj, dependos de tio, kion mi sukcesos.
4. Havas sian propran komercan administradsistemon kaj kapablas labori pri projektoj de ajna komplekseco en ĝi.
Laborante pri principoj – kiam vi skribas ĉiujn viajn taskojn en ia tekstsistemo, ne forgesu iujn ajn interkonsentojn, puŝu ĉiujn, aperu ĉie ĝustatempe, sciu kio estas grava kaj kio ne gravas momente, vi neniam perdas taskojn. La ĝenerala trajto de tiaj homoj estas, ke kiam oni konsentas pri io kun ili, oni neniam zorgas pri tio, ke ili forgesos; kaj vi ankaŭ scias, ke ili skribas ĉion kaj tiam ne faros mil demandojn, kies respondoj jam estis diskutitaj.
5. Demandas kaj klarigas ajnajn kondiĉojn kaj enkondukojn
Ankaŭ ĉi tie estas du ekstremoj. Unuflanke, vi povas esti skeptika pri ĉiuj enkondukaj informoj. Homoj antaŭ vi elpensis iujn solvojn, sed vi pensas, ke vi povas fari pli bone kaj komenci rediskuti ĉion, kio venis antaŭ vi: dezajno, komercaj solvoj, arkitekturo ktp. Ĉi tio malŝparas multan tempon kaj por la programisto kaj por tiuj ĉirkaŭ li, kaj havas negativan efikon sur fidon ene de la firmao: aliaj homoj ne volas fari decidojn ĉar ili scias, ke tiu ulo revenos kaj rompos ĉion. La alia ekstremo estas kiam programisto perceptas ajnajn enkondukajn, teknikajn specifojn kaj komercajn dezirojn kiel io ĉizita en ŝtono, kaj nur kiam alfrontita kun nesolvebla problemo, li komencas pensi pri ĉu tio estas kion li faras entute. Bona programisto ankaŭ trovas ĉi tie mezan vojon: li provas kompreni la decidojn faritajn antaŭ aŭ sen li, antaŭ ol la tasko iras en evoluon. Kion volas komerco? Ĉu ni solvas liajn problemojn? La produktoprojektisto elpensis solvon, sed ĉu mi komprenas kial la solvo funkcios? Kial la teamgvidanto elpensis ĉi tiun specialan arkitekturon? Se io ne estas klara, tiam vi devas iri demandi. En la procezo de ĉi tiu klarigo, bona programisto povas vidi alternativan solvon, kiu simple ne okazis al neniu antaŭe.
6. Plibonigas procezojn kaj homojn ĉirkaŭ vi
Estas multaj procezoj okazas ĉirkaŭ ni - ĉiutagaj renkontiĝoj, renkontiĝoj, scrums, teknikaj recenzoj, kodaj recenzoj ktp. Bona programisto stariĝos kaj diros: rigardu, ni kunvenas kaj diskutas la samon ĉiusemajne, mi ne komprenas kial, ni povus same pasigi ĉi tiun horon ĉe Contra. Aŭ: por la tria sinsekva tasko mi ne povas eniri la kodon, nenio estas klara, la arkitekturo estas plena de truoj; Eble nia revizia kodo estas lama kaj ni devas refactori, ni refaktoru la renkontiĝon ĉiujn du semajnojn. Aŭ dum koda revizio, persono vidas, ke unu el siaj kolegoj ne sufiĉe efike uzas certan ilon, kio signifas, ke li devas veni poste kaj doni kelkajn konsilojn. Bona programisto havas ĉi tiun instinkton; li faras tiajn aferojn aŭtomate.
7. Bonege administri aliajn, eĉ se ne administranto
Ĉi tiu kapablo ligas bone kun la temo "solvi anstataŭ krei problemojn." Ofte, en la teksto de la vakantaĵo por kiu ni kandidatiĝas, nenio estas skribita pri administrado, sed tiam, kiam vi alfrontas problemon ekster via kontrolo, vi ankoraŭ devas administri aliajn laŭ unu maniero aŭ alia, atingi ion de ili, se vi forgesis — puŝu, certigu, ke ili ĉion komprenis. Bona programisto scias, kiu interesiĝas pri kio, povas voki renkontiĝon kun ĉi tiuj homoj, noti interkonsentojn, sendi ilin al malstreĉo, memorigi ilin en la ĝusta tago, certigi, ke ĉio estas preta, eĉ se li ne estas persone rekte respondeca pri ĉi tiu tasko, sed lia rezulto dependas de ĝia efektivigo.
8. Ne perceptas sian scion kiel dogmon, estas konstante malfermita al kritiko
Ĉiuj povas memori kolegon de antaŭa laboro, kiu ne kapablas kompromisi sian teknologion kaj krias, ke ĉiuj brulos en la infero pro iuj malĝustaj mutacioj. Bona programisto, se li laboras dum 5, 10, 20 jaroj en la industrio, komprenas, ke duono de lia scio estas putra, kaj en la restanta duono li ne scias dekoble pli ol li scias. Kaj ĉiufoje kiam iu malkonsentas kun li kaj proponas alternativon, ĝi ne estas atako kontraŭ lia egoo, sed ŝanco lerni ion. Ĉi tio permesas al li kreski multe pli rapide ol tiuj ĉirkaŭ li.
Ni komparu mian ideon de ideala programisto kun la ĝenerale akceptita:
Ĉi tiu bildo montras kiom da el la supre priskribitaj punktoj rilatas al la kodo, kaj kiom ne. Disvolviĝo en produkta kompanio estas nur unu tria programado, la ceteraj 2/3 malmulte rilatas al kodo. Kaj kvankam ni skribas multe da kodo, nia efikeco tre dependas de ĉi tiuj "sensignifaj" du trionoj.
Specialiĝo, ĝeneralismo kaj la 80-20 regulo
Kiam homo lernas solvi kelkajn mallarĝajn problemojn, studas longe kaj malfacile, sed poste solvas ilin facile kaj simple, sed ne havas kompetentecon en rilataj kampoj, tio estas specialiĝo. Ĝeneralismo estas kiam duono de la trejna tempo estas investita en la areo de propra kompetenteco, kaj alia duono en rilataj areoj. Sekve, en la unua kazo, mi faras unu aferon perfekte kaj la ceterajn malbone, kaj en la dua, mi faras ĉion pli-malpli bone.
La 80-20 regulo diras al ni, ke 80% de la rezulto venas de 20% de la penado. 80% de enspezo venas de 20% de klientoj, 80% de profito venas de 20% de dungitoj, ktp. En instruado, tio signifas, ke 80% de scio ni akiras en la unuaj 20% de tempo pasigita.
Estas ideo: kodistoj devas nur kodi, dizajnistoj nur desegni, analizistoj devas analizi, kaj administrantoj nur administru. Laŭ mi, ĉi tiu ideo estas venena kaj ne tre bone funkcias. Ĉi tio ne temas pri ĉiuj devi esti universala soldato, ĉi tio temas pri ŝparado de rimedoj. Se programisto komprenas almenaŭ iomete pri administrado, dezajno kaj analizo, li povos solvi multajn problemojn sen impliki aliajn homojn. Se vi bezonas fari ian funkcion kaj poste kontroli kiel uzantoj laboras kun ĝi en certa kunteksto, kio postulos du SQL-demandojn, tiam estas bonege povi ne distri la analiziston per ĉi tio. Se vi bezonas enmeti butonon analoge kun ekzistantaj, kaj vi komprenas la ĝeneralajn principojn, vi povas fari ĝin sen impliki dezajniston, kaj la kompanio dankos vin pro tio.
Entute: vi povas pasigi 100% de via tempo por studi kapablon ĝis la limo, aŭ vi povas pasigi la saman tempon sur kvin areoj, niveligante ĝis 80% en ĉiu. Sekvante ĉi tiun naivan matematikon, ni povas akiri kvaroble pli multajn kapablojn en la sama kvanto de tempo. Ĉi tio estas troigo, sed ĝi ilustras la ideon.
Rilataj kapabloj povas esti trejnitaj ne je 80%, sed je 30-50%. Post pasigado de 10-20 horoj, vi rimarkeble pliboniĝos en rilataj areoj, akiros multe da kompreno pri la procezoj okazantaj en ili kaj fariĝos multe pli aŭtonomia.
En la hodiaŭa IT-ekosistemo, estas pli bone havi kiel eble plej multajn kapablojn kaj ne esti spertulo pri iu el ili. Ĉar, unue, ĉiuj ĉi tiuj kapabloj rapide velkas, precipe se temas pri programado, kaj due, ĉar 99% de la tempo ni uzas ne nur bazajn, sed certe ne la plej altnivelajn kapablojn, kaj tio sufiĉas eĉ en kodado, eĉ en bonegaj kompanioj.
Kaj finfine, trejnado estas investo, kaj diversigo estas grava en investoj.
Kion instrui
Do kion instrui kaj kiel? Tipa programisto en forta firmao regule uzas:
- komunikado
- mem-organizado
- planado
- dezajno (kutime kodo)
- kaj foje administrado, gvidado, datuma analizo, skribo, rekrutado, mentorado kaj multaj aliaj kapabloj
Kaj preskaŭ neniu el ĉi tiuj kapabloj intersekcas kun la kodo mem. Ili devas esti instruitaj kaj altgradigitaj aparte, kaj se tio ne estas farita, ili restos sur tre malalta nivelo, kio ne ebligas uzi ilin efike.
En kiuj areoj indas disvolviĝi?
-
Molaj kapabloj estas ĉio, kio ne koncernas premado de butonoj en la redaktilo. Tiel ni skribas mesaĝojn, kiel ni kondutas en kunvenoj, kiel ni komunikas kun kolegoj. Ĉi tiuj ĉiuj ŝajnas esti evidentaj aferoj, sed tre ofte ili estas subtaksitaj.
-
Memorganiza sistemo. Por mi persone, ĉi tio fariĝis supergrava temo dum la pasinta jaro. Inter ĉiuj bonegaj IT-laboristoj, kiujn mi konas, ĉi tiu estas unu el la plej evoluintaj kapabloj: ili estas superorganizitaj, ili ĉiam faras tion, kion ili diras, ili scias precize kion ili faros morgaŭ, post semajno, post monato. Estas necese konstrui sistemon ĉirkaŭ vi, en kiu ĉiuj aferoj kaj ĉiuj demandoj estas registritaj; tio multe faciligas la laboron mem kaj multe helpas interagi kun aliaj homoj. Mi sentas, ke dum la pasinta jaro, evoluo en ĉi tiu direkto plibonigis min multe pli ol plibonigi miajn teknikajn kapablojn; mi komencis fari signife pli da laboro po unuo de tempo.
-
Proaktiva, malferma menso kaj planado. La temoj estas tre ĝeneralaj kaj esencaj, ne unikaj al IT, kaj ĉiuj devus disvolvi ilin. Proaktiveco signifas ne atendi signalon por ekagi. Vi estas la fonto de eventoj, ne reagoj al ili. Malferma menso estas la kapablo trakti ajnan novan informon objektive, taksi la situacion izole de la propra mondkoncepto kaj malnovaj kutimoj. Planado estas klara vizio pri kiel la hodiaŭa tasko solvas la problemon por la semajno, monato, jaro. Se vi vidas la estontecon preter specifa tasko, estas multe pli facile fari tion, kion vi bezonas, kaj ne timu post tempo rimarki, ke ĝi estis malŝparita. Ĉi tiu kapablo estas precipe grava por kariero: vi povas sukcese atingi rezultojn dum jaroj, sed en la malĝusta loko, kaj eventuale perdi la tutan amasigitan bagaĝon kiam evidentiĝas, ke vi moviĝis en la malĝusta direkto.
-
Ĉiuj rilataj areoj al la baza nivelo. Ĉiu havas siajn proprajn specifajn areojn, sed gravas kompreni, ke pasigante 10-20 horojn da tempo por ebenigi iun "fremdan" kapablon, vi povas malkovri multajn novajn ŝancojn kaj kontaktopunktojn en via ĉiutaga laboro, kaj ĉi tiuj horoj povas sufiĉu ĝis fino de kariero.
Kion legi
Estas multaj libroj pri mem-organizado; ĝi estas tuta industrio, kie iuj strangaj uloj skribas kolektojn de konsiloj kaj kolektas trejnadojn. Samtempe, estas neklare, kion ili mem atingis en la vivo. Tial gravas meti filtrilojn sur la aŭtorojn, rigardi kiuj ili estas kaj kion ili havas malantaŭ ili. Mia evoluo kaj perspektivo estis plej influitaj de kvar libroj, ĉiuj el ili laŭ unu maniero aŭ alia rilata al plibonigo de la kapabloj priskribitaj supre.
1. Dale Carnegie "Kiel Gajni Amikojn kaj Influi Homojn". Kulta libro pri mildaj kapabloj, se vi ne scias kie komenci, elekti ĝin estas gajna eblo. Ĝi estas konstruita sur ekzemploj, estas facile legebla, ne postulas multe da peno por kompreni tion, kion vi legas, kaj la akiritaj kapabloj povas esti aplikataj tuj. Ĝenerale, la libro kovras la temon pri komunikado kun homoj.
2. Stephen R. Covey "7 Kutimoj de Tre Efika Homoj". Miksaĵo de malsamaj kapabloj, de proaktiveco ĝis mildaj kapabloj, kun emfazo pri atingado de sinergio kiam vi devas turni malgrandan teamon en grandegan forton. Ĝi ankaŭ estas facile legebla.
3. Ray Dalio "Principoj". Rivelas temojn de malfermiteco kaj proaktiveco, bazitaj sur la historio de la firmao kiun la aŭtoro konstruis, kiun li administris dum 40 jaroj. Multaj malfacile gajnitaj ekzemploj el la vivo montras kiom antaŭjuĝema kaj dependa homo povas esti, kaj kiel forigi ĝin.
4. David Allen, "Getting Things Done". Deviga legado por lerni memorganizadon. Ĝi ne estas tiel facile legebla, sed ĝi provizas ampleksan aron da iloj por organizi vivon kaj aferojn, ekzamenas ĉiujn aspektojn detale kaj helpas vin decidi kion precize vi bezonas. Kun ŝia helpo mi konstruis mian propran sistemon, kiu ebligas al mi ĉiam fari la plej gravajn aferojn sen forgesi pri la ceteraj.
Vi devas kompreni, ke nur legado ne sufiĉas. Vi povas gluti almenaŭ libron semajne, sed la efiko daŭros kelkajn tagojn, kaj tiam ĉio revenos al sia loko. Libroj estu uzataj kiel fonto de konsilo, kiu estas tuj provata en la praktiko. Se vi ne faras tion, tiam ĉio, kion ili donos, estas iom da plilarĝigo de viaj horizontoj.
fonto: www.habr.com