Rääkisin ühe tuttavaga teemal, mida on võimalik IT-s karjääri poolest üldse peale hakata. Enda üllatuseks leidsin, et ükski IT-d õpetav Eesti kool ei loetle just kuigi põhjalikult võimalusi ja ameteid, millega pärast nende stuudiumi lõpetamist on võimalik tegeleda, ja samuti ei kujuta ka paljud tudengid ette, mida nad täpsemalt pärast kooli tegema hakkavad. Hakkasin neid seetõttu ise kirja panema ja mõningase mõtlemise järel jõudsin järgmise tabelini (kliki, et suurendada):

Siin on ära toodud üksteisest ülesannete sisu poolest erinevad ametid, mille täiskohaga pidajaid ma ise näinud olen, ja kus tarkvaraalasest (päris tervet IT-d+arvutiteadust ei oleks jõudnud ühte tabelisse kirja panna) haridusest kasu oleks. Grupeering on mõneti meelevaldne ja mõnes situatsioonis liigitataks ameteid ehk teisiti. Siiski läheb praktiliselt igas tarkvaraprojektis peaaegu kõiki ka vaja, kuigi olenevalt projekti suurusest võib mõnele neist kuluda 0,1% ühemehefirma omaniku ajast kuni tervete meeskondadeni. Nt Microsoftis on tiim, kes päevast päeva lihtsalt jooksutab igapäevaste Office’i buildide suitsuteste. Testid käivad automaatselt, kuid sellegipoolest on vaja, et keegi kontrolliks, et kõik sujub, koordineeriks parandusi, saadaks vastavaid teavitusi jne.

Peale nende on muidugi veel musttuhat spetsiifilisemat varianti, üks huvitavamaid ametinimetusi, mida ma olen kohanud, oli Emulation Ninja Microsofti XBoxi divisjonis, aga need on üldjuhul teisendid tabelis toodud ametitest.

Kuna aga need ametid erinevad mitte ainult tehnoloogia, vaid ka sisu poolest, oleks väga hea, kui ülikoolid mõistaksid nende olemasolu ja annaksid ka spetsiifilisemaid teadmisi, kuidas ühes või teises hakkama saada. Igaüks neist vääriks eraldi loengukursust, kardetavasti utoopia, aga unistada ju võib.

Veel: siit ei järeldu, et ma pooldaksin mingit superkitsast spetsialiseerumist. Minu peamine point on, et nende tegevusalade olemasolu tuleb teadvustada ning ennast nende läbiviimiseks korralikult ette valmistada, kuid õige professionaal võiks vallata päris paljusid selle tabeli lahtritest. Inimene on ikkagi generalist, spetsialiseerumine on putukatele

Mult on vahetevahel küsitud nõu, kuidas efektiivsemat CV-d kirjutada. Internetis on selle kohta küll üsna palju materjali, aga kuna minu lauale jõuavad vahel ikka päris traagilised kirjutised, ütlen sõna sekka.

Esimene küsimus on tegelikult, kas meil on üldse CV-d vaja? Minu meelest on nii värbamisel kui töölesaamisel oluliselt, oluliselt parem variant CV-d mitte kasutada. Nagu Toots ütles, parim soovitus mehele on mees ise. Ehk siis, kui tegemist on inimesega, kelle teod räägivad iseenda eest (on näiteks valmistanud või kirjutanud midagi, millest kõik teavad), milleks talle siis veel CV? Väga abiks on siin muidugi ka võimalikult laia sotsiaalse võrgustiku (vana kooli mõttes, mitte tingimata rate.ee) omamine, et saaksid õigel ajal õiges kohas olla.

Kui me esimesele küsimusele vastates siiski leiame, et meil piisavalt tuntust ei ole, tuleb järgmiseks uurida ühtteist selle ettevõtte kohta, kuhu me tahame pääseda. On muidugi ka geneerilisi CV-sid, mida spämmitakse tuhandesse eri kohta, et ehk näkkab, need on kergesti äratuntavad ning jäetakse enamasti kõrvale.

Kõige olulisem asi ettevõtte kohta on see, kas seal värbavad inimesi teised tehnikud või on tegemist 100% HR funktsiooniga (mingi osalus on HRil muidugi alati, oluline on see, kes otsuseid teeb). Esimene variant on üldiselt palju parem, teist liiki firmad soovitan ma madalamaks prioriteediks võtta.

Kui HRile silmajäämiseks tuleb enamasti õigeid buzzworde teada, siis tehnikute osas on kuldreegliks: kui sa ise kedagi tööle võtaksid, siis mis laadi inimest sa tahaksid? See mõtlemine aitab enamasti sobivust kontrollida. Vaata, mis on selle ettevõtte või organisatsiooni ning tema juhtkonna põhiväärtused, mõtle, kas sa jagad neid, ning too nad seejärel enda juures esile.

Näiteks mulle isiklikult jäävad silma need, kes demonstreerivad:

• Taiplikkust
• Pealehakkamist
• Passionit
• Võimet asju ära teha
• Koostööoskust

Kui mainid oma CVs mitmesuguseid üritusi või projekte, mida oled algatanud ja korraldanud, siis see on hea, kuna näitab pealehakkamist.

Kui kirjutad projektidest, milles oled osalenud, too kindlasti välja, mis oli sinu isiklik panus sellesse. Millega sa hakkama said? See näitab asjade ära tegemise võimet.

Kas tegeled tööväliselt mingite lahedate tehnoloogiliste asjadega? Proged ehk midagi või ehitad roboteid? See näitab taiplikkust ja passionit.

Kui sul on kogemusi suuremas tiimis koos töötamise alal, siis seda peaks ka mainima, sealhulgas oma rolli tiimis. Et siin projektis oli 3 progejat ja mina tegin neile tehnilist disaini, see ütleb ühtteist koostöövõime kohta. Paljud programmeerijad on üksikud hundid, omaette teevad asjad ära, aga suures projektis ei saa teistega koos töötatud.

See oli nüüd minu isiklik vaatenurk, aga metaõppetund on alati järele uurida, kes antud ettevõttes värbamisega tegeleb, mis on nende metoodika ja väärtused, mille alusel nad inimesi hindavad, ning seejärel natuke kodutööd teha.

Ja last but not least - korrektsus on alati abiks, enamik komavigu ei tekita päris sellist piinlikkust nagu ülaloleval pildil, aga lohaka mulje jätavad ikka.

Hulkuvate Kasside Riiklik Inspektsioon tellis tarkvarafirmalt Joostes Marss täiendusi oma andmeregistrile. Ülesandepüstitus oli küllaltki selge ja põhjalik ning projektijuht Joosep küsis programmeerija Priidult, kui kaua asjaga läheb. Neli nädalat, vastas Priit, Joosep pani igaks juhuks puhvri mõttes veel nädala otsa ning teatas klient Kustavile, et viie nädala pärast saab asja kätte.

Priit hakkas asjaga hoolega pihta, Joosep käis regulaarselt pärimas, kuidas läheb, ja üldiselt asi sujus. Nagu programmeerimise puhul ikka ette tuleb, tekkis ka siin ootamatuid viivitusi, kuid viienda nädala lõpuks teatas Priit siiski, et kood on valmis.

Joosep helistas Kustavile, et asjad on korras, aga arvas seejärel, et vaatab ise ka siiski funktsionaalsust. Tulemused tõstsid tal ihukarvad püsti – enamvähem iga viie kliki järel rakendus crashis ja praktiliselt ühtki kasutusjuhtu polnud võimalik algusest lõpuni läbi käia.

Joosep tormas kõva kisaga Priidu juurde, et mis toimub. Aset leidis järgmine kahekõne.

Joosep: Mis bl*#¤% selle koodiga toimub??
Priit: Kood sai just valmis ja kogu funktsionaalsus on teostatud.
Joosep: No aga miks see crashib siis, jo*#¤ma*#¤% ?!?
Priit: No aga keegi pole ju seda testinud, loomulik ju, et koodis pole kõik asjad kohe päris õiged.
Joosep: Kas sa ise ei testinud siis oma asja?
Priit: Testimiseks polnud aega ette nähtud, ise küsisid, et kui kaua teostamisega läheb, mitte testimisega. Ja üldse oled ise üks hu*”%¤% !!

Oops.

Asi lõppes sellega, et Joosep istus ise järgmise paari nädala hilisõhtud töö juures ja testis erinevaid stsenaariume ning käis ka Priidul piitsaga kannul. Mõlemad olid stressis ja magamata, Kustav õiendas iga päev, et mis ikkagi toimub, pidi ju valmis olema, ning kui projekt lõpuks üle anti, tekkis seal ikkagi probleeme, sest testimine polnud nii põhjalik, kui vaja oleks olnud.

Lisaks süüdistasid Joosep ja Priit pidevalt ka teineteist asja nässukeeramise eest, Joosep leidis, et Priidu tulemus ei oleks tohtinud selline olla, Priit omakorda, et kõik on Joosepi süü selle pärast, et projektigraafikusse ei arvestatud testimise ja vigade parandamise aega.

Milles siis tegelikult asi? Minu isiklikus kogemuses ei hävi projektigraafikud mitte niivõrd sellepärast, et hinnangud oleksid ebatäpsed, kui sellepärast, et mingid tegevused unustatakse lihtsalt graafikusse lisamata.

Iidseks vaidluste allikaks on siin, et kes peaks tegelikult hoolt kandma, et kõik tegevused oleks arvesse võetud? Programmeerijad sõimavad enamasti projektijuhte, samas õppis Joosep Audentese koolis rahvusvahelist ärijuhtimist ja kuigi ta saab hästi hakkama kliendisuhtluse ja raha lugemisega, on temalt mõneti utoopiline loota, et ta täpselt teaks, mida kõike üks tarkvaraarendaja peab tegema, et asi valmis saaks. Seda enam, et “valmis” võib tegelikult erinevate inimeste jaoks tähendada väga erinevaid asju, näiteks:

• Funktsionaalsus on koodiridadena olemas
• Keegi on rakenduse peamised kasutajajuhud läbi käinud
• Programmeerija on rakendusele kirjutanud unit testid ja need töötavad
• Testija on mingi testimisplaani alusel kontrollinud, et funktsionaalsus töötab
• Tellija on formaalse kava alusel kontrollinud mitmesuguste nõuete täidetust

Jutu peamine moraal kõigile tarkvaraprojektides osalejaile on:

• Täpsustada, mida nimetatakse valmis olekuks, kuna see on olenevalt inimese taustast ja ametist väga suuresti vaataja silmades
• Teha vahet lubaduste (commitmentide), ligikaudsete esmärkide ja tõenäosuslike ajahinnangute vahel ning iga mainitava kuupäeva puhul täpsustada, millega on tegemist.

Konkreetselt programmeerijad on mitmel korral mulle kurtnud, et nende ajagraafikud on ebarealistlikud, sest ei võta kõiki tegevusi arvesse. Peamine nõu, mida ma neile olen andnud, on:

• Tavaliselt on ebarealistlik oodata, et projektijuht ise kõiki tehnilisi tegevusi meeles jõuab pidada ja nende kohta eraldi ajahinnanguid küsida. Seega peaks programmeerija tõusma oma positsioonilt natuke kõrgemale ja ise järele mõtlema, mis on tegelikult projekti õnnestumiseks vaja teha.
• Selle asemel, et keskenduda oma ajahinnangute kitsale definitsioonile ja anda ainult koodikirjutamiseks kuluv aeg, eelda, et niikuinii tuleb sul teha hulk muid asju nagu unit testide kirjutamine, komponenditestimine, süsteemitestimine, vigade parandamine jne. Kui on teada, et keegi teine mingi osa nendest tegevustest enda kanda võtab, on väga hea, aga üldiselt seda ei juhtu ja vaikimisi on parem need kohe hinnangutena kirja panna. Mõte siis selles, et lõpuks tuleb need tegevused niikuinii ära teha, iseasi, kas ületundidena või mingil mõistlikul ajal.
• Kuus kuud hiljem ei mäleta üldjuhul keegi, kui kaua see asi tegelikult aega võttis, küll aga mäletavad inimesed hästi, kas 1) tähtajad pidasid 2) kui hästi tulemus toimis. Töötasin kord koos ühe arendajaga, kelle ajahinnangud alati väga kõrged tundusid. Kui teda aga lähemalt üle kuulata, tuli välja, et tegelikult oli ta graafikusse lisanud ka väga täpsed ja detailsed ajahinnangud sellele, kui palju teste ta ise tahab kirjutada, kui palju võtab aega funktsionaalsuse testijale üleandmine ja tutvustamine, potentsiaalsete vigade parandamine jne. Ja tulemuseks oli, et kuigi ta lõpetas oma lõigu nominaalselt teistest hiljem, oli ta projekti testimis- ja stabiliseerimisfaasi lõpuks teistest ees ning tema kood töötas palju paremini kui kellelgi teisel. NB! See ei tähenda, et kõik võiks lihtsalt oma ajahinnanguid hakata kahega korrutama, vaid seda, et inimesel tuleb tõesti hoolikalt järele mõelda, kui palju nendele ekstra tegevustele kulub ja neid detailselt hinnata!
• Vahel väidavad ülemused või kliendid, et testimine pole oluline, või et selle eest niikuinii ei maksta. Ma arvan, et selline seisukoht on tihti tingitud valdkonna puudulikust tundmisest. Kui keegi tõesti ütleb, et ärme neid lisategevusi graafikusse pane, siis ma soovitan nad enda jaoks sellegipoolest kirja panna ning lihtsalt “koodikirjutamisele” juurde liita. Elu on näidanud, et lõpuks tuleb sellised tegevused nii või teisiti ära teha ja kuna shit flows downhill, näidatakse pärast ikka näpuga progeja peale, et tema tegi halvasti.

On arenguvestluste aeg. Praegu on neljas aasta, mil see ülesanne minu ametijuhendis seisab, ja panen sel teemal lõpuks mõned kogutud mõtted kirja.

Tarkvara tellija seisukohalt näeb projekt välja umbes selline:

Ehk siis nad eeldavad, et saavad mingi raha eest kaetud ära erinevate valdkondade kompetentsi mingite tarkvarakomponentide osas. Erinevaid komponente võib teostada sama või erinevad inimesed, eeldame siinkohal lihtsuse mõttes, et iga ruutu täidab erinev inimene.

Kui meil tuleb nüüd tööle ilma eelneva kogemuseta nooremarendaja, on tema kompetents tegelikult selline:

Selge see, et tellijale selline valgete laikude jätmine ei meeldi, sellepärast aitavad meie uut arendajat üldjuhul kolleegid kõrvalruutudest, näiteks inimesed, kes seonduvaid komponente haldavad, annavad tehnilist nõu, analüütik hoiab asjal rohkem silma peal jne.

Igal inimesel tekib mingi ala, mille raames ta projekti üldist käiku mõjutab. Ja kuna tellija maksab meile lõppkokkuvõttes kogu ruumi täitmise eest, on kasu, mida inimesed projektile toovad, otseselt seotud nende mõjuala suurusega. Teisisõnu, kui palju on teistel teda ümbritsevatel inimestel temast abi, võrreldes sellega, kui palju teised peavad teda järele aitama.

Tegelikus elus tuleb neid dimensioone veel juurde, näiteks saavad inimesed oma mõju avaldada projektijuhtimise ja kliendiga suhtlemise liinis, aga põhimõte jääb samaks.

Ja tavaliselt ei jää inimesed igaveseks ajaks abivajajaks, vaid arenevad nii kaugele, et täidavad oma valdkonna adekvaatselt ära ja hakkavad ise pigem teistele nõu andma:

Mis on jutu moraal:

See mudel annab meile ka automaatselt meetodi inimeste tulemuste ja kasutoomise hindamiseks. Meil pole vaja lugeda koodiridu ega bugisid ega function pointe ega spetsifikatsioonilehekülgi ega laua taga istutud tunde. Kõik need mõõdikud illustreerivad vaid pisikest lõiku sellest, mida inimene tegelikult teeb, kui paljude teiste projektiosalistega ta suhtleb ja millist kasu ta neile saab tuua, rääkimata asjaolust, et need andmed on väga kergesti võltsitavad

Vaja on ainult vestelda kõnealuse inimese kaastöötajatega erinevatest dimensioonidest (arendaja puhul näiteks teised arendajad, tema lähim analüütik, testija, projektijuht, klient jne) ja küsida, millist kasu on inimene X teie vaatekohalt nii projektile kui ka teile endale toonud, ning me saamegi hea pildi sellest, kes on tegelikult väärtuslik, kes mitte.

Kokkuvõtlikud järeldused:

1. Arendaja loomulik karjääriprotsess on, et ta vajab aja jooksul vähem kõrvalist abi ja hakkab järjest rohkem aitama teisi. Esimeseks sammuks on siin üldjuhul oma loomuliku ruudukese äratäitmine ning teiseks laienemine mõnda kõrvalasuvasse, vastavalt isiklikele huvidele ja projekti vajadustele.
2. Igal inimesel tuleb ette loomulik piir, millest alates ainult omaenda kitsas töövaldkonnas opereerimine pole piisav, et igal aastal palka juurde küsida, kuna ta on iseenese ruumi lihtsalt ära täitnud. Samas on igas projektis alati küllaga valgeid laike, mille täitmisega rohkem kasu tuua.
3. Ja kõige olulisemana minu isiklik põhireegel arenguvestluste osas: inimese väärtus projektile on võrdeline talle töökaaslastelt osaks saava respektiga.

Umbes kümme aastat tagasi oli mul kord kõrge palavik, mis takistas kooli või tööle minekut. Arvuti taha suutsin end siiki vedada ja kirjutasin teatava Kivirähu teksti põhjal üles Vana Programmeerija loo.

Kümne aasta juubeli puhul panin ta siia taas kirja. Nendele, kel huvi asja võõramaalastega jagada, tõlkisin selle millalgi ka inglise keelde.

Vana Programmeerija

Öösel toodi firmasse uus mees.
“Said su siis nõusse,” ütles üks programmeerija kaastundlikult. “Küllap jootsid su täis, nii nagu meid kõiki. Kes siis kaine peaga sellisesse firmasse tuleb!”
“Kas tead, kuhu kadus too mees, kelle asemele sind värvati?” küsis teine kaastöötaja. “Projektijuht lõi ta maha. Lihtsalt lõi maha ja kõik. Palju mehi on tema rusika läbi oma otsa leidnud.”
“Nii ongi õige!” ütles uus mees rahulikult. “Kus seda enne nähtud, et firmas ei tapeta! Mina olen vana häkker, olen kõik operatsioonisüsteemid ise läbi testinud ning iga kord on taplemist olnud. Vat vanasti, siis olid ikka mehed! Igaüks käis majas ringi, juhtmeots käes, ja kui sai, siis laskis voolu! Mina ainsana jäin hinge, lõpetasin edukalt projekti ja kauplesin end uude kohta. Jah, mina tunnen tarkvara tegemise kombeid!”
Ja ta ronis magamiskotti ning jäi norinal magama.
Hommikul tundis projektijuht uue mehe vastu huvi.
“Kus ta on?” küsis ta analüütikult. “Tutvustan talle meie firma tavasid.”
Analüütik läks näost punaseks ja lõi silmad maha.
“Kuidas nüüd öelda… Istub jututoas… Ma küll ütlesin, aga…”
“Mis!” röögatas projektijuht. “Laiskleb! Kas ta peab meie firmat laatsaretiks või! Tuhat nullpointerit! Näita, kus ta on!”
Programmeerija vedeles tõesti jututoas ning haigutas aeg-ajalt magusalt.
Projektijuhti nähes ta naeratas unelevalt.
“Mõtlesin just sellest ajast, mil ma veel noor olin,” ütles ta. “Siis olid mehed selgest rauast. Mina isegi olen ju teab kui mitu korda haljast assemblerist bugisid rookinud. Ükskord juhtus sihuke ette, et hoia ja keela! Kolm korda tuli ringi kompileerida. Aga ma talle andsin!”
“Mida!” käratas projektijuht. “Sa veel seletad, lurjus!”
“Nonoh!”, ütles mees pahaselt. “Hoia oma pudrumulk vaos, kui sa häkkeriga kõneled. Ega ma oma juttu lõpetanud pole. Teinekord tuli andmebaasimootorit parandada – t erve kollektiiv läks selle pärast peast segi, aga siis leidis terav kirves kivi! “Noh, roju!” ütlesin ma talle. “Nüüd ma su jahvatan!” See oli ka üks kodeerimine, mida tänaseni meenutatakse.”
Projektijuht kuulas ja läks raevust kollaseks.
“Kas sa tead, kellega sa praegu räägid!” kisendas ta. “Sa räägid projektijuhi endaga!”
“Mis projektijuht sina oled!” lõi vana programmeerija käega. “Selliseid projektijuhte on ennegi nähtud. Vaata vanasti, siis olid projektijuhid. Silmad olid teistel punnis, käisid trampides mööda koridori ja vandusid nii , et kõik masinad käigu pealt GPF-i andsid. Sinusuguseid keskkoolihäkkereid ei lastud uksest sissegi, nad tõid õnnetust kaasa. Mine parem oma tuppa ja küll mina siin asjad korda sean. Mina tunnen C++’i nagu oma pük se.”
“Nii!” pöördus ta seejärel analüütiku poole. “Mitut CASE-vahendit te kasutate?”
“Ühte,” vastas see hämmeldunult.
Vana programmeerija vangutas pead.
“Kus seda enne nähtud!” ütles ta. “CASE-vahendeid peab olema vähemalt seitse ja diagramme tuleb üle joonistada kaksteist korda päevas. Nii oli vanasti alati. Saada mehed joonistama!”
“Mulle tundub, et…” alustas jahmunud projektijuht, aga vana programmeerija käskis tal pudrumulgu kinni pidada.
Serveri kettaruumi kulutas vana programmeerija rohkem kui kõik ülejäänud kokku ja käskis finantsdirektoril seejärel uut riistvara muretsema minna.
“Nii ei jätku meie rahadest kuigi kauaks,” söandas finantsdirektor poetada.
“Firmas peabki vähe raha olema,” vastas vana programmeerija kindlalt. “Omal ajal, kui ma FreeBSD-ga tegelesin, ei saanud keegi seitse kuud sentigi palka. Mis teie siin ka üldse tarkvarategemisest teate.”
“Mis firma tarkvara kasutatakse?” uuris ta seejärel analüütikult.
“Microsofti,” vastas too.
“See tuleb kohe maha kustutada,” ütles vana häkker. “Kus seda enne nähtud, et Microsofti tarkvara kasutatakse! See toob ju sulaselget õnnetust! Kõik vanad programmeerijad teavad, et Microsoftis pesitsevad kurjad vaimud. Ru ttu tarkvara ketastelt maha! Mul on meeles üks juhtum, kus kah keegi rumal projektijuht Microsofti tarkvara arvutitesse lasi installeerida. Sealt firmast ei pääsenud peale minu keegi eluga, operatsioonisüsteemidest ronisid aga deemonid välja ja käisid öösiti magamiskottidest meeste verd imemas.”
Jubedusega kuulanud töötajad formateerisid kiiresti kõik kõvakettad üle.
“Jeesus Maria!” hüüdis vapustatud projektijuht. “Nüüd meie tähtajad hävivad! Ma lähen hulluks!”
“Tarkvaratootmisel peabki hulluks minema, siin teisiti ei saa,” nõustus vana häkker. “Meil läks omal ajal kogu kollektiiv hulluks.”
“Projektijuht ägas ja pages oma tuppa varju.
Vana programmeerija jalutas mööda ruume ning sattus viimaks süsopi manu.
“Süsteem töötab valesti,” ütles ta pärast hetkelist mõtlemist.
“Mul on siin graafiline abivahend, mis süsteemi jälgimisega tegeleb,” vastas süsop.
Vana häkker vilistas.
“See’p see on!” ütles ta. “Graafiline kasutajaliides! Kus seda enne nähtud on! Kellel oli vanasti graafiline kasutajaliides? Mitte kellelgi! Käsurida on kõik, mis häkkeril vaja läheb. Graafiline kasutajaliides on ainult eksitamiseks mõeldud.”
Ta lükkas süsopi kõrvale, kustutas X-Windowsi ning läks tööst väsinuna uuesti puhkama.
Siis anti teada peatsest voolukatkestusest. Projektijuht, kelle nägu reetis, et tema paar viimast tundi pole olnud kergete killast, väljus oma toast ja käskis tööd salvestada.
“Rumalus!” leidis vana programmeerija. “Las aga olla! Pidage kõik oma pudrumulgud kinni, küll mina juba andmetega hakkama saan!”
Siis tuligi voolukatkestus ja pooleliolevad tööd hävisid.
õhtul pidid Microsofti esindajad, kellega firma koostööd tegi, tulema projekti seisu üle vaatama.
Kuna süsop oma tööd teha ei saanud, ei saadud ka andmeid taastada ning Microsofti esindajad said kurjaks.
“Nüüd me oleme pankrotis,” oigas juhtkond.
“Firma peabki pankrotti minema,” õpetas vana programeerija, kes hetkekski rahu ei kaotanud. “Mis firma see on, mis pankrotti ei lähe?! Nii palju, kui mina olen töötanud, pole ükski firma pankrotistumata jäänud! Omal ajal…”
Aga ta ei jõudnud lõpetada, sest enne seda jõudsid kohale Microsofti juristid, kes ta seal koos teiste töötajatega kinni võtsid ja Bill Gatesi enda ette toimetasid.
Bill istus väärikalt troonil ja kohendas oma kandilisi prille.
“Midagi halba teiega siin ei juhtu,” ütles ta. “Hakkate vaid minu produktide kallal kodeerijateks nagu kõik need, kes enne teid minu valdustesse sattusid. Nüüdsest olete mu sulased!”
Tekkis hetkeline vaikus ja kohe seejärel oli kuulda vana programmeerija häält, kes Wordi patchis.
“Kus seda enne nähtud, et Word PC peal jookseb!” pahandas ta. “Wordi koht on HP peal.”
“Kas see pole mitte see vana programmeerija!” hüüatas Bill selge hirmuga. “Jälle siin!”
“Mina ikka,” vastas häkker. “No miks su prillid küll kandilised on? Need on ju alati olnud ümmargused.”
“Viige ta ruttu tagasi!” karjatas Bill. “Ruttu!”
Ning juristid viisid vana programmeerija minema.
Järgmisel päeval istus ta terminali taga ja mängis muda, kui sisse astusid kaks meest.
“Vajame kogenud programmeerijat!” hõikas üks neist.
“Siin ma olen,” vastas vana programmeerija ja läks meestega kaasa.

Mitmesuguste uuringute põhjal on leitud, et ligi pooli alustatud tarkvaraprojekte võib lugeda ebaõnnestunuks. Seega, kui lugejal on olnud tegemist mõne tarkvaraprojektiga, on suure tõenäosusega olemas ka kogemus mõne puusse läinud projektiga. Huvitav on aga jälgida, milliseid abinõusid selle puhul ette võetakse. Selgub näiteks, et inimesed on õnnetud ja rahulolematud, mida teha? Juhtkond korraldab neile kõva peo, uskudes, et selle abil saab kõik korda, aga kas see oli tegelikult asi, mida vaja?

Steve McConnell laiendab oma suurepärases raamatus “Software Project Survival Guide” Maslow hierarhia ideed tarkvaraprojektidele.

Järgneval skeemil on klassikaline Maslow hierarhia inimeste kontekstis:

Laiendades sama ideed tarkvaraprojektile saame aga sellise diagrammi:

Ja nagu inimeste puhul, pole meil mõtet tegeleda hierarhia ülemiste osadega, kui alumised on rahuldamata. Oletame, et mul on paha tuju. Sõbrad kutsuvad mind kinno, et asja parandada, aga see ei muuda midagi, kui minu probleem on tekkinud hoopis sellest, et mul on kõht tühi! Samamoodi ei aita inimestele peo korraldamine, kui probleemiks on see, et tähtajad on ebarealistlikud ning inimesed peavad kogu aeg ületunde tegema.

 

Kui ehitajad ehitaksid maju samamoodi nagu programeerijad kirjutavad programme, siis esimene rähn hävitaks tsivilisatsiooni. – Murphy seaduste kogust

Leidsin riiulist mingi ehitusinseneridele mõeldud tehnilise taskuraamatu (pole aimugi, kuidas see sinna sai). Muuhulgas on seal palju tabeleid mitmesuguste materjalide omaduste kohta: tellised, teras, vineer, tihedus, kõvadus, tugevus. Arusaadav, et iga korralik insener peab omama ülevaadet, milliste materjalidega ta töötab, mis on nende tugevuspiirid ja muud tehnilised omadused. Seda enam on hämmastav, kui vähesed programmeerijad teavad, millest nad tegelikult oma programme kokku panevad. Rakendusprogrammeerija ei tea, mis toimub klassiteekide sees, mida ta kasutab. Teekide kirjutaja ei tea, mis toimub operatsioonisüsteemis. Süsteemprogrammeerija ei tea, mis toimub riistvaras. Kõige selle juures on imekspandav, et tarkvara üldse vahel töötab ja midagi mõistlikku teeb.

Kiire test: Kui sa oled C# programmeerija, siis kas sa tead, kui suur on mscorlib.dll? Kasutad XMLi? Kui suur on System.Xml.dll? (Java, C++ jne spetsialistid võivad mõelda oma põhiliste klassiteekide ja runtime’ide peale). Ei tea? Tegemist on umbes samasuguse probleemiga, kui ehitaja ei tea, kui palju kaalub tellis, sest iga kord kui keegi vastava rakenduse käima paneb, mõjutab laetud teekide hulk rakenduse mälutarvet ja sellega otseselt programmi jõudlust. Analoogiliselt, kui sa kasutad näiteks mingit stringitöötlusteeki, on hea teada, mis on nende operatsioonide tegelik ajaline keerukus, kui pilditöötlemisteeki, siis millised on selle sisemised andmestruktuurid, et saaks hinnata mäluvajadust jne.

Objekt-orienteeritud programmeerimine on väga hea asi, aga ebasoovitava kõrvalefektina on see veelgi süvendanud olukorda, kus inimesed:

1. ei tea, mis klassiteegi sees toimub, sest kõik on ilusasti ära peidetud, pakendatud ja kapseldatud
2. ei oska ilma spetsiaalse teegita ise üldse ühtki probleemi lahendada

Kord saadeti mind asja uurima suure, tähtsa ja rikka kliendi juurde, kes kurtis, et tema veebiserver ei skaleeru. Lasin nende avalehe profileerijast läbi ja leidsin tuhandeid String.Concat väljakutseid. Selgus, et nad panevad suure hulga oma HTMList lihtsalt stringiliitmise teel kokku, mis on C# kasutades muidugi rumal. Tegemist on tüüpilise näitega, kus programmeerija ei tea, kuidas tema vahendid tegelikult töötavad.

Osaks minu tööülesannetest on aeg-ajalt potentsiaalsete töösoovijatega vestlemine (veel enne tegelikku intervjuud/katseid). Küsin sealhulgas nende käest lihtsaid tehnilisi küsimusi, et leida, kas on üldse mõtet edasi vestelda või on tegu mõlemapoolse ajaraiskamisega. Tuleb siis selline tegelane, küsin tema käest, et kui tal on programmis näiteks massiiv punaseid palle ja rohelisi palle, kuidas oleks kõige parem neid sorteerida, nii et punased pallid satuvad algusesse ja rohelised lõppu. Tema selle peale, et teeks ArrayListi ja kasutaks siis selle Sort meetodit. Kas ta teab, kuidas Sort meetod töötab? Ei. Aga kui ta peaks ise sellise meetodi kirjutama? Vaikus. Bzzzzzt, järgmine, palun. Esiteks pole klassiteekides leiduvad üldotstarbelised sorteerimisalgoritmid antud ülesande puhul sugugi optimaalsed, teiseks pole mul midagi peale hakata inimesega, kes arvutiteaduse põhikontseptsioonidega hätta jääb (nagu ehitusinsener, kes füüsikaeksamil põrub). Aja- ning mäluvajaduse keerukusest ei jõudnud muidugi rääkima hakatagi.

Uuri allikteksti, sula ühte koodiga – Linus Torvalds

Inimesed küsivad mult vahel nõu programmeerimisõpikute kohta. Häid õpikuid on palju, aga minu meelest on hea programmeerija parimaks lektüüriks hea kood Mitmesuguste andekate inimestega koos töötamise järel olen oma Microsofti-kogemuse juures rõõmus võimaluse üle igasugust huvitavat koodi lugeda, Windows, Office, .Net Framework, kõigis neis on geniaalseid lahendusi, rääkimata asjade mõistmisest tulenevast rahuldusest ja teadmistest, mis võimaldavad mul oma tööd efektiivsemalt teha (ma ei räägi siin mingitest sala-APIdest, vaid lihtsalt algoritmide tasemel mõistmisest). Väljaspool Microsofti on loomulikult samuti tuhandeid võimalusi uurida, kuidas asjad töötavad, olgu siis Open/Shared Source’i maailmas või mujal, ja suureks vaheks hea programmeerija ning tipp-programmeerija vahel on tihti see, kui palju ta igasuguste vidinate uurimisele on aega kulutanud. Kui alliktekstid pole saadaval, uuri jõudluskarakteristikuid, profileeri klassiteeke jne, et aru saada, kuidas asjad töötavad.

Ja hoidu rähnide eest

 

We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.” – Larry Wall

Klassikalised kristlikud voorused on: mõistlikkus, mõõdukus, meelekindlus, õiglus, usk, lootus ja armastus. Samas, nii palju kui ma ka ei püüaks klassikalist vooruslikku elu elada, on vähemalt minu naise arvates mind märgatavalt paremini varustatud laiskuse, kannatamatuse ja edevusega. Kuna aga vähemalt professionaalses elus on viimased kolm mind kõvasti rohkem edasi aidanud kui esimesed seitse, siis tuleb ilmselt olukorrast võtta, mis võtta annab Siin ei tule asja muidugi nii mõista, et me neid kolme omadust kogu aeg ja igas situatsioonis peaksime kasutama, küll aga on nad meile suureks abiks oma igapäevase koodi kirjutamisel.

Esimene voorus: laiskus

Tarkvarafirmal Joostes Marss tuleb teha Hulkuvate Kasside Riiklikule Inspektsioonile statistiliste aruannete moodul, toomaks eraldi välja, kui palju erinevate ajaperioodide lõikes koeri ja kasse kaotatakse ja leitakse. Jagatakse siis ära: pooled aruanded Priidule ja pooled Pärtlile. Priit hakkab asjaga kohe hoolega pihta, kirjutab ühe lehekülje keerulist andmebaasikoodi teise järel. Ajaperioodide arvestamisel on teatavasti palju erijuhtumeid, teha päringut näiteks juuni viimasest pühapäevast 5. septembrini pole triviaalne ja Priidu kood koosneb lõpuks suurest hulgast if-then-else klauslitest, igaühe sees omakorda keeruline arvutus. Priit muudkui kirjutab, möödub päev ja teine, projektijuht Joosep küsib, kuidas läheb, Priit näitab suurt hulka koodi ja seletab pikalt, kui keerulise ülesandega ikka tegemist on, ja kuidas tal veel kolm korda nii palju koodi tuleb kirjutada, enne kui asi valmis. Kuna koodihulgast on ilmselgelt näha, et asjad edenevad, siis Joosep rahuneb natuke.

Pärtel ei tee samal ajal pealtnäha suurt midagi, nokitseb asja kallal, sirgeldab ühtteist paberile, lõpuks teeb siiski kompilaatori ka lahti. Joosep on mures ja küsib Pärtli käest, et näe, Priidul juba nii palju koodi valmis, mida sina teed? Pärtel vastu, et pole hullu, küll saab. Ja teatab õhtul, et temal on kõik valmis. Joosep ei usu, sest koodi pole pealtnäha nagu ollagi, aga näeb siis, et tõepoolest, kõik töötab, kiiresti ja korralikult. Pärtel ei viitsinud palju koodi kirjutada ja tekitas lihtsalt denormaliseeritud vahetabeli, kuhu enne aruannete koostamist andmed kopeeritakse, ja mille pealt päringute tegemine on selge, lihtne ja lühike.

Tegelikult on laiskus arvutitega lahutamatult seotud. Kuna arvuti on loodud selleks, et inimese eest töö ära teha, poleks virk inimene kunagi sellise leiutise peale tulnud. Hea programmeerija püüab teha kõik, et omaenda vaeva võimalikult vähendada. Las arvuti töötab, tema on rauast. Ma ise pean konkreetset kooditoksimist küllaltki tüütuks ega viitsi sellega palju vaeva näha, selle asemel püüan nuputada, kuidas võimalikult vähese arvu ridadega hakkama saada või üleüldse mõnd olemasolevat komponenti kohandada. Selline nuputamine on palju huvitavam ja inimesele kohasem ning rahuldust pakkuvam tegevus, rääkimata sellest, et tähtajad saavad kiiremini valmis ja ka tulemus on enamasti kvaliteetsem (vigade hulk kipub kasvama koos koodi hulgaga).

Laiskus soodustab veel mitmeid häid harjumusi nagu

• korduvate tegevuste jaoks spetsiaalsete utiliitide kirjutamine
• koodi hoolikam testimine ja debugimine (sest tarkvara põhiteoreemi järgi kulub meil testimata ja debugimata koodi peale rohkem aega)
• selge ja lihtsa koodi kirjutamine, selle kommenteerimine ja dokumenteerimine (et hoida kokku aega, mis muidu kuluks teiste inimeste aitamisele ja rumalatele küsimustele vastamisele)
• taaskasutatavusele optimiseerimine, et me ei peaks sama koodi mitu korda kirjutama
• jne

Teine voorus: kannatamatus

Ma arvan, et inimeste kannatamatus on asjaolu, mis on otseselt põhjustanud Moore’i seaduse ja palju muud lahedat.

Kannatamatusega saab mõõta näiteks selliseid asju:

• Mitu korda ma pean sama koodi uuesti kirjutama, enne kui ma selle jaoks uuestikasutatava mooduli teen?
• Mitu korda ma viitsin oma programmi testides samu liigutusi teha kuni ma sagedasemate operatsioonide jaoks lühema ja intuitiivsema meetodi välja mõtlen?
• Kui kaua ma jaksan mingi olemasoleva tarkvara järel oodata enne kui ma parema ja kiirema lahenduse välja mõtlen ja sellega palju raha teenin?
• Kui kaua ma mõne inimese või teenuse järel ootan, enne kui ma asja ise kiiremini ja efektiivsemalt ära teen või veel parem, automaatse lahenduse leiutan?
• Kas ma kannatan olukorda, kus inimesed minu tiimis kirjutavad tuhat rida koodi, kui hakkama saaks ka viiesajaga? Või korraldan ma neile koolituse, et nad parematest metoodikatest aimu saaksid?

Kolmas voorus: edevus

Kui Pärtel oli oma aruanded ennetähtaegselt valmis saanud, ei jäänud ta siiski rahule sellega, et juba enne olemas olnud, valmis koodis käisid paljud aruanded liiga aeglaselt. Päringud olid kirjutatud täpselt kliendi tellimuse kohaselt, imiteerides protsesse, mida klient Kustavi alluvuses töötavad kontorirotid enne kas siis Exceli või ka paberi ja pliiatsi abil sooritasid. Selle tõttu kopeeriti ka andmeid liigselt ühest kohast teise, päringud käisid üle seitsmeteistkümne erineva tabeli korraga jne. Pärtel uuris veel natuke asja, kombineeris mõned tabelid kokku, lisas paar indeksit, kirjutas mõne stored procedure’id lihtsalt päringusse lahti jne. Järgmisel päeval ehmus Joosep, et kas kõik testandmed on ära kustutatud või milles asi, et aruanded järsku mitukümmend korda kiiremini toimivad. Pärtlile ei läinudki eriti korda, kas kliendi jaoks on oluline vahe, kas aruanne käib kümme sekundit või kümnendik sekundit, kuid tal oli võimalus näidata, kes on ettevõttes alfaprogrammeerija.

Hubris ei tähenda küll päris täpselt edevust, aga mulle meeldib “edevus” tähendusväljana isegi rohkem. Tegemist on jõuga, mis paneb programmeerijat seatud ärilisi eesmärke ja tehnilisi nõudeid ületama, mis sunnib neid kirjutama eriti elegantset koodi, mis vastab headele tavadele ja standarditele, kuid teeb asju siiski efektiivsel ja isikupärasel moel. Tihti ei pane lõppkasutaja selliseid töövõite otseselt tähelegi, aga edevale programmeerijale on tähtis eelkõige kolleegide imetlus. Seetõttu katsub ta kirjutada koodi, mille kohta kellegil midagi norida ei oleks, mis on tarkvara kvaliteedi seisukohalt muidugi väga hea.

Lisaks koodi efektiivsusele avaldub edevus muidugi ka muudes asjaoludes:

• Kes saab oma töölõigu esimesena valmis?
• Kelle koodis on kõige vähem vigu?
• Kelle tehtud kasutajaliides on kõige uhkem?

Kui edevat programmeerijat selliste asjade eest piisavalt tunnustada, kasvab produktiivsus mühinal, piitsa ja präänikut ei lähe üldse vajagi.

Motivatsiooni saame jagada positiivseks (me teeme midagi, et meiega midagi head juhtuks) ja negatiivseks (teeme midagi, et halb juhtumata jääks), samuti väliseks (keegi teine tahab, et me midagi teeks) ja sisemiseks (ise tahame seda teha).

Selle põhjal saame laias laastus neli liiki motivatsioonifaktoreid: kolm neist ei tööta ja üks töötab. Sellegipoolest kasutab 95% maailma ettevõtetest enamasti mingit kombinatsiooni kolmest mittetöötavast meetodist.

Kõige olulisem tähelepanek on, et väline motiveerimine üldjuhul ei tööta, ei hea ega halvaga, vaatleme seda mõnede näidete varal:

Sõjaväes õpivad inimesed küllaltki kiiresti, et käsk on vanem kui meie ja käsule vastuhakkamisel on enamasti kurvad tagajärjed, olgu tegemist siis kuitahes rumala käsuga. Ka tsiviilelus juhib nii mõnigi organisatsioonijuht oma inimesi nagu sõdureid: “Teed sellepärast nõnda, et mina ütlen nii, muidu oled vallandatud! Ja jutul lõpp!!”

Programmeerijad, sindrinahad, arvavad aga enamasti, et nad teavad ise kõige paremini, kuidas asju teha (ja tihti teavadki), ja reageerivad seetõttu kamandamismeetodile lastes oma produktiivsuse allapoole igasugust arvestust. Teiseks eeldab kamandamismeetod arvestatavat mikromanageerimist, niipea kui piitsaplaksutataja silmapiirilt kaob, lastakse end jällegi lõdvaks ja ei tehta üldse midagi. Asi lõpeb sellega, et juht kurnab ennast ära, tehtud ei saa aga ikka midagi.

Hoiatava näite sellest, kuidas väline halvaga ähvardamine ei aita, leiame tegelikult meditsiinist. Südameoperatsioonil käinud inimesi hoiatatakse üldjuhul, et kui nad oma eluviise (olgu siis liigse söömise, joomise, suitsetamise vms osas) ei muuda, siis nad surevad varsti ära. Kui paljud inimesed aga tegelikult ennast parandavad? Selgub, et 2 aastat pärast operatsiooni on 90% patsientidest tagasi endiste harjumuste juures!

Ühesõnaga, kui isegi surmaga ähvardamine ei aita, kui inimesel puudub tegelik sisemine soov midagi muuta, kui palju lootust on siis otsesel ülemusel?

Teine viis, kuidas inimesi püütakse panna midagi tegema, on neid ühel või teisel viisil ära ostes, olgu tegemist siis raha, nänni, “kuu parima töötaja” tiitli või muude vahenditega.

Esimene probleem sellise lähenemise juures on, et tarkvaraprojekti juures on äärmiselt raske leida mingit lineaarset väärtust, mida mõõta ja seejärel rahasse ümber kantida. Kui premeerida näiteks koodiridade arvu, kirjutab programmeerija kas suure hulga kommentaare või formaadib koodi niiviisi, et see võimalikult pikk välja tuleks, või teeb otseselt sohki, lisades projektile hulga “võltskoodi”, mis tegelikult midagi ei tee.

Kui premeerida ennetähtaegset ülesannetega valmis saamist, “täidetakse” ülesanne ilma testimata ja muul viisil üle nurga lastes.

Kui premeerida vähest vigade arvu, teeb programmeerija testijaga diili, et vigu ei panda kirja ja statistikas näeb kõik ilus välja (kui me maksame testijale lisatasu selle järgi, kui palju vigu ta leiab, lähevad programmeerija ja testija tülli ning tiimitöö lendab vastu taevast).

Sõltumata sellest, millise meetodi me leiutame, on programmeerija üldjuhul piisavalt taiplik, et optimiseerida oma tulemust vastavalt sellele, mida me parajasti mõõdame, ning tulemus saab enamasti palju hullem, kui enne mõõtmisviisi sisseviimist.

Peamine viga, mis mõlemal juhul tehakse, on see, et inimese sisemine motivatsioon asendatakse välisega. Kui ma tahan kirjutada head koodi sellepärast, et mulle meeldib hea tulemus, siis ma pingutan selle nimel, et kood tuleks võimalikult hea. Kui mulle selle eest aga raha pakutakse, siis hakkan ma mõtlema, et “ma pean kirjutama head koodi, et raha saada”. Väline motivaator on aga alati nõrgem kui sisemine ning paradoksaalsel kombel on mul äkitselt hoopiski vähem soovi oma tööd võimalikult hästi teha.

Kuidas sisemist motivatsiooni kasvatada? Kui ma teaksin sellele küsimusele täpset vastust, siis juhiksin praegu mõnd Fortune 100 ettevõtet, aga arvamusi siiski:

On väga oluline, et töötaja jagaks ettevõtte identiteeti ja peaks ettevõtte eesmärke enda omadeks. Siinkohal on suureks abiks, kui ettevõttel on mingil viisil üllas või võimas visioon, millega inimestele meeldib ennast samastada. Miljonid väga andekad inimesed töötavad küllaltki väikese raha eest heategevates organisatsioonides, sest neile meeldib töötada õilsa eesmärgi nimel, isegi kui nad ise on lihtsalt raamatupidajad või itimehed, mitte ei jaga isiklikult nälgivatele lastele leiba.

Kommertsettevõttel on muidugi natuke raskem üllas olla, aga ka siin leiab hea tahtmise korral lahenduse. Microsofti missioon on aidata inimestel kogu maailmas oma tööd efektiivsemalt teha. Paljude teiste firmade missioon on Microsoft troonilt tõugata ja seeläbi “õiglus jalule seada”

Teine identiteedi aspekt on seotud töötaja kolleegidega. Kui inimesed tunnevad end kokkukuuluvatena nagu perekond, on nad vastastikku lojaalsed ja üksteisele pühendunud. Kui minu töökaaslased on mulle olulised, pole mulle vaja mingit välist motivaatorit, et nende nimel ekstra pingutada ja ühise eesmärgi nimel asjad võimalikult hästi valmis teha.

Kolmandaks on vaja, et ettevõtte kultuuris väärtustatakse siiralt head tulemust. Meile kõigile meeldib, kui meid hinnatakse ja respekteeritakse, seda siis nii ülemuste kui ka kolleegide poolt. Kui programmeerija ülemuseks on aga endine müügimees, kes C-l ja Javal vahet ei tee, jääb see vajadus aga rahuldamata ning mingil hetkel langeb paratamatult ka motivatsioon.

Üks olulisemaid asju, mille üle mul oma Microsofti-kogemuse juures hea meel on, on võimalus töötada koos väga erineva tausta ja päritoluga inimestega. Ainuüksi minu otseses alluvuses on olnud inimesi Hiinast (sh nii emamaalt, Taiwanist kui ka Hong Kongist), Indiast, Kanadast, Poolast, Slovakkiast, Türgist, USAst ja Venemaalt, lisaks kolleege kõikvõimalikest muudest kohtadest Soomest Botswanani. Konkreetselt arendajate osas on ameeriklased Microsoftis muuseas suur vähemus ja mõnes divisjonis ei moodusta isegi mitte suurimat rahvusgruppi.

Selle juures on huvitav tähele panna, kuidas kellegi kultuuriline ja majanduslik taust on inimesi vorminud. Ühelt poolt võib igas keskkonnas kohata nii geeniusi kui ka luusereid, IQ ja töökuse monopoli pole ühelgi piirkonnal, aga sellegipoolest torkavad silma mõned iseärasused.

Ameeriklased elavad tugevate kapitalistlike traditsioonidega arenenud tööstusühiskonnas, kus valitseb tugev sisemine konkurents ettevõtete ja ka indiviidide vahel. Ettevõtete seas on tihti väga tugev spetsialiseeritus, igaüks on leidnud endale konkreetse kitsa turuniši, millelt oma kasumit saada. Ameerikasse kolides üllatas mind suuresti, kui palju siin ikkagi erinevaid kaupu ja teenuseid on võimalik saada, mis on kõik selle konkurentsi ja spetsialiseerumise tagajärg. Üksikisikute tasemel paistavad silma kaks aspekti: esiteks tohutu ettevõtlikkus – peaaegu kõigil minu ameeriklastest tuttavatel on kunagi olnud oma äri, nad plaanivad seda tulevikus luua või vähemalt unistavad sellest. Teiseks aspektiks on jällegi seesama spetsialiseeritus, Ameerikas kohtab väga palju inimesi, kes on mingi konkreetse eriala äärmiselt tugevad spetsialistid, kuid nad jäävad hätta, kui on tegemist millegagi, mis otseselt nende valdkonda ei puutu. Samuti toetub ameeriklane hädas palju konkreetse spetsialisti abile, selle asemel, et asju ise korda ajada, olgu tegemist siis elektriku, politseiniku või advokaadiga.

Indialaste puhul on oluline vahe, kas me räägime tüüpilisest väljarännanud IT-spetsialistist või inimesest Bombay tänavalt. Tohutu ülerahvastatuse tõttu on Indias lääne inimese jaoks kujuteldamatu konkurents ülikoolikohtadele ja headele ametipostidele. Kraadiõppesse pääseb vaid maksimumhinnetega ja isegi kõrgelt haritud inimesel pole enamasti muud valikut, kui töötada Ameerika firma tech suppordis ja kuulata redneckide virisemist, et miks nende modem ei tööta. Kui siia lisada veel takistused, mida USA immigratsiooniteenistus seab osadest riikidest sisserändajaile, saame kokku terve hulga sõelasid, millest tüüpiline Indiast pärit itimees on pidanud läbi saama. Sellega seoses järgivad nad tihti punktuaalselt igasuguseid tobedamaid ja vähemtobedamaid reegleid (ehk täidavad vene korraldusi saksa täpsusega), kuna nende kogemuse järgi võib reegli eiramine kaasa tuua rongist maha jäämise.

Idaeurooplased on tihti vastupidise mentaliteediga. 50 aastat kommunismiaega on neile õpetanud, et reeglid on juhuslikud ning suvalised (isegi kui nad vabamas ja loogilisemas ühiskonnas seda ei ole) ja neid võib enamasti eirata. Vahel on see halb, vahel hea, olenevalt sellest, kas tulemuseks on geniaalne innovatsioon või faux pas, mille tõttu teised peavad ületunde tegema.

Hiinlaste juures on huvitaval kombel esindatud jooned kõigist ülaltoodutest: suurrahva mentaliteedist tingitud mõningane teadmatus muu maailma osas, rahvaarvust tingitud tihe konkurents ja kommunistlikust riigikorrast tulenev teatav vajadus igapäevaelus vahel mõningast osavust kasutada.
Samas on Hiina kultuurile lääne omaga võrreldes omane küllaltki tugev kollektivism. Kui Ameerikas on vanasõna, et varajane lind saab ussi kätte (early bird gets the worm), siis Hiinas on väidetavalt vanasõna, et varajane lind lastakse maha ehk siis hoopis teine suhtumine individuaalsesse initsiatiivi. Eriti Hiina filiaalidega asju ajades torkab silma, et inimesed võtavad vastu mingi otsuse ja siis kohalik ülemus räägib kõigi eest, võrreldes sellega, kuidas Euroopa või Ameerika filiaalis igaüks isiklikult esile püüab tikkuda.

Eestlastel on idaeurooplaste alamliigina veel üks eripära: väikerahvana on Eestis põhimõtteline struktuurne puudus inimestest. Ühemiljonilise rahvaarvuga riigis tuleb ära täita needsamas võtmepositsioonid (olulised riigiametid, põhiliste majandusvaldkondade juhtivate ettevõtete direktorid jne), mis sajamiljoniliseski, aga sobivad kandidaadid tuleb leida palju väiksema seltskonna seast. Kuna igalühel polegi erilist soovi suur juht ja otsustaja olla, põrkavad rahvusvaheliste firmade esindajad Eesti filiaalidega tegeledes kokku nende jaoks kummalise probleemiga, kus keegi ei tahagi eriti ülemus olla ja teeb pigem oma tavalist tööd. Oma tavalises suurkorporatsiooni keskkonnas on nad harjunud pigem olukorraga, kus igale juhtivale kohale on kohe kümme kandidaati, kuna inimestel pole muud varianti silmapaistmiseks. Eestis on aga igal soovijal küllaltki lihtsalt võimalik saada kas seltskonnaajakirja veergudele, televisiooni, parlamenti või mõne top 100 ettevõtte juhikohale, mis enamiku inimeste ambitsioonid rahulikult ära maandab – kui mujal on tegemist tõsise ambitsiooniüleküllusega, siis Eestis selle puudusega.
Samuti täidetakse Eestis sarnaseid ülesandeid tihti palju väiksema arvu inimestega, kui mujal ning igaüks peab tihti ära katma palju laiema vastutusala kui rahvarohkemas ühiskonnas tavaks. Kui Redmondis on Microsofti Office’i divisjonis terve eraldi tiim, mis tegeleb ainult build toolide ja skriptidega, siis Eestis teeb programmeerija ise kõik vajaliku muu töö kõrvalt ära. Seetõttu on eestlane itimehena tihti palju laiema profiiliga, kuid tal puudub tavaliselt sügavam eriteadmine oma valdkonnast. See tähelepanek ei kehti muidugi mitte ainult IT kohta, mulle tundub, et näiteks ameeriklasega võrreldes on eestlane ka üleüldiselt varmam avaldama amatöörlikku arvamust mõnel suvalisel poliitilisel või filosoofilisel teemal.

Mis on jutu moraal: Nagu alguses öeldud, ei mõjuta kultuurikeskkond kellegi oskust või võimet oma igapäevaseid tööülesandeid täita ja kõigist ülaltoodud statistilistest tähelepanekutest on palju erandeid. Siiski on hea, kui meeskonnas on esindatud erineva taustaga inimesed, kes lähenevad probleemile erinevalt ning suudavad näha midagi, mis teistel ehk tähele panemata jääb. See ei kehti muidugi mitte ainult rahvuse, vaid ka sotsiaalse või majandusliku päritolu, hobide, selle, kas tegemist on linna- või maainimesega jms kohta. Mida rohkemad on erinevad kogemused ja oskused meeskonnas esindatud, seda väiksem on risk ja seda tugevam lõpptulemus.