IT-alan työpaikat

[dropadrop]

Kieltämättä mielenkiintoista keskustelua meneillään. Mikä tekee ihmisestä hyvän arkkitehdin? Miten kovia principal engineerejä tehdään? Jos joku juniori haluaa kovapalkkaiseen positioon millaisia uraliikkeitä pitää tehdä? Tähän liittyy paljon sellaista hiljaista tietoa jota ei koulun penkiltä saada.

Ne juniorit joiden olen nähnyt nousevan ovat aina olleet todella halukkaita ymmärtämään asioita juuria myöten. Se tarkottaa siis, etteivät vain ”hoida tikettiä” vaan tutkivat aina vähän sen ympäriltä… Miksi näin kävi? Miten toi kirjasto siis toimii? Miten me nyt oikeasti päädytään tähän? Se uteliaisuus vaan ajan myötä tarkoittaa, että he ymmärtävät asiat paremmin kuin muut - ja sitä kautta muuttuvat aina vaan seniorimmiksi.

Arkkitehtien tapauksessa on taas vähän eri. Oon nähnyt aivan huippuluokan koodaajia / adminejä jotka eivät olleet erityisen hyviä arkkitehteja. Tossa mun on vaikea sanoa mitkä atribuutit erottaa, huomaan vaan että kun oikea tyyppi astuu puikkoihin tapahtuu kummia:
- teknologiavalinnat paranee
- tiimien toimintamallit yhtenäistyy eivätkä edes valita
- muutokset / korjaukset / parannukset saa skaalattua paljon nopeammin
- helpompi hahmottaa etukäteen uusien hankkeiden riskit ja ongelmakohdat
- helpompi keskustella abstraktisti pidemmälle tähtäimelle suunnitelmien ulkopuoleltakin

Isossa ympäristössä tommoset tyypit on ihan korvaamattoman arvokkaita.

 

[godzilla43]

Vaikea sanoa mikä tekee hyvän arkkitehdin. Moni noista kädet savessa kavereista on kyllä teknisesti eteviä. Arkkitehdin pitää jakaa töitä tiimille ja sen arkkitehtuurin(suunnittellun,speksaamisen) lisäksi ottaa itse ne jäljelle jääneet "paskat" duunit. Tosin hyvä arkkitehti voi olla myös ei kädet savessa oleva kaveri kunhan tuntee teknologian jolla ollaan kehittämässä ja toimii enemmän projektipäällikkönä(tai projektipäällikönä) sekä pre-salesissa. Sanoisin myös että hyvästä kehittäjästä voi tulla ok arkkitehti mutta hyvästä teknisestä arkkitehdistä tulee todennäköisemmin huono teknologia johtaja. Nämä henkilöt monesti eivät ole kovin hyviä puhumaan c-tason johtajille(tai muillekkaan ei-teknisille henkilöille) kun pitäisi kauppaa tehdä eikä myöskään hallinnolliset asiat kiinnosta vaan mielummin tehdään kehitystä.

Hyvällä arkkitehdillä on myös ylensä aikaa kehittää prosesseja työpaikan sisällä, osallistua uusiin pre-saleseihin, mentoroida.. vaikka olisikin monta projektia kun on antanut töitä tiimillensä eikä ole jatkuvasti hiomassa jotain pientä yksityiskohtaa.

 

[ravallo]

Allekirjoitan täysin sen, että sille huippukoodarille voisi hyvinkin kannattaa maksaa se 10x -liksa, ihan niinkuin tuossa aiemmin sanottiin niin kun vastaan tulee oikeasti hankala ongelma, niin suorituskyvyn ero huipun ja keskinkertaisen välillä on ääretön; huipulla asia valmistuu ajassa x, keskinkertaisella se ei valmistu koskaan. Ihan toinen asia on se, monestiko firman sisäinen palkkapeli päättyy oikeudenmukaisesti niin että se kaveri joka tienaa sen 200k on oikeasti se kovin jätkä. Monesti, erityisesti kun puhutaan nimenomaan huippukoodareista, ei arkkitehdeistä, kaverit eivät välttämättä ole edes niin kunnianhimoisia siellä firman organisaatiossa, vaan kunnianhimo näkyy enemmän siellä softan konepellin alla.

Pari kertaa tullut vastaan että hyvässä uranosteessa ja kovassa maineessa oleva kaveri onkin paljastunut yhden hitin ihmeeksi, joka on sopivassa saumassa sattunut opiskelemaan jonkun kovassa demandissa olevan jutun esm. devopsin automaatiopuoleen tai pilvisoftan tunkkaukseen liittyen, ja sillä ollaan sitten laukaistu ura maatakiertävälle radalle - vaikka juttu on lopulta ollut sellainen että kuka tahansa peruskaverikin sen olisi voinut opiskella. Sitten kuljetaan palaverista toiseen laukomassa "fiksuja" juttuja ylemmälle johdolle ja "rivikoodarit" pyörittelee selän takana päätään.

Oma lukunsa ovat myös "autistimaiset" tyypit, jotka saattavat olla aivan korvaamattomia joidenkin spesifien ongelmien ratkaisussa, mutta kommunikaatiotaidot eivät ihan riitä normaaliin ryhmätyöskentelyyn.

Ja hyvistä arkkitehdeista, no, ratkaisukeskeisyys olis aika kova juttu noin niinkuin alkuun... Alkaa palaa käpy noihin "ei pysty, ei kykene, ei se täällä kuitenkaan onnistu, ei nää osaa" -tyyppeihin.

 

[mopnex]

Isot sovelluskehityshankkeet tehdään kuitenkin tiimin/tiimien toimesta niin on vaikea nähdä miten 1 lähes cowboy-koodarimainen tekisi siitä kokonaisuudesta paremman. "Teen tämän yksin koska olen paras" on enemmänkin harhaista ja tiimin koheesiota haittaavaa sekä epäammattimaista. Hyvä sovelluskehittäjä pystyy tuomaan rinnallaan olevista tyypeistä sen parhaan esiin. Kaikkea ei voi osata, eikä voikaan mutta se että osaa myöntää kun ei tiedä ja pyytää apua kun tarvitsee on tähdellistä.

Itse kun toimin konsulttina niin en kyllä allekirjoita alkuunkaan tuota, että "hakataan kasaan jotain paskaa ja jätetään tunkio taakse". Kaiken lähtökohtana on oltava se, että kaikki tekemisen kerrokset on automatisoitu/koodina (infra, CI/CD). Testaaminen ei ole sellainen asia joka jätetään tekemättä, vaan sitä tehdään eri kerroksilla (unit, integration, e2e). Tähän päälle tietysti parikoodaus, code-review ymv:t sen mukaan mikä tiimille toimii. On toki ehdottoman tärkeätä että tiimissä on niitä kokeneita kavereita, mutta lähes yhtä tärkeää on että siellä on muutama ei-niin-kokenut. Noissa tilanteissa kokeneemmat saavat keskittyä niihin haastavimpiin ongelmiin, ja tavallaan isompaan kuvaan - kuitenkin samalla joutuu palaamaan niihin fundamentteihin kun joku asia on opetettava ja selitettävä ymmärrettävällä tavalla hieman juniorimmalle tekijälle. Siinä oppii väkisin itsekin, kun toinen kysyy ehkä jotain mitä ei ole tullut ajatelleeksi tai toisesta näkökulmasta. Kyllä se kaikki tämä lähtee ammattiylpeydestä ja intohimosta tähän tekemiseen.

Kammoksun koko "sankarikoodari" "rockstarakoodari" jne.. nimityksiä, noissa on sivuutettu tyystin se miten kuitenkin 99% maailman softasta saadaan toimivasti maaliin: tiimityönä ja asiakasta unohtamatta. Usein se hybris huokuu yli ja kaikki mitä asiakas sanoo on aina väärin, teknisesti, eikä edes yritetä ymmärtää sitä isompaa kuvaa ja tarvetta. Siinä on paljon mahdollisuuksia vaikuttaa siihen, että asiakas saa mitä haluaa. Se mitä on järkevä tehdä, mikä toimii asiakkaalle, on myös usein lähellä sitä mitä asiakas on pyytänyt, mutta meillä ammattilaisina on myös kykyä kertoa jos asian voi tehdä paremmin toisella tavalla. Oli se "paremmin" sitten helpommin ylläpidettäväksi, täyttää 95% tarpeista 50% työmäärällä, sopii kokonaisarkkitehtuurin paremmin, tuo paremman lopputuloksen, tässä kohtaa on oikeasti järkevä panostaa enemmän jne...

Olen työskennellyt monien loistavien sovelluskehittäjien kanssa, ja kyllä meillä kaikilla on silti omat heikkoutemme niiden vahvuuksien lisäksi. Tämän takia hyvä tiimi on paljon enemmän kuin osiensa summa - tiimillinen huippukoodareita ei välttämättä ole paras ratkaisu [Google].

Usein jo se, että on selitetty miksi eri ratkaisut on valittu(ja mitä tradeoffeja tähän liittyi) säästää todella paljon aikaa.

Pragmatic programmer kirjaa voi myös suositella ihan varauksetta. Jos tietää niin nopea lukea, mutta hyvä kerrata. Jos ei tiedä niin aikalailla oleellista olisi tietää.

The Pragmatic Programmer

Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of mod...

www.goodreads.com

Tässä tulikin hyvin asiaa, mutta tuo Pragmatic Programmer on omasta mielestä kertaluokkaa parempi kuin Clean Code.

 

[ravallo]

Isot sovelluskehityshankkeet tehdään kuitenkin tiimin/tiimien toimesta niin on vaikea nähdä miten 1 lähes cowboy-koodarimainen tekisi siitä kokonaisuudesta paremman. "Teen tämän yksin koska olen paras" on enemmänkin harhaista ja tiimin koheesiota haittaavaa sekä epäammattimaista. Hyvä sovelluskehittäjä pystyy tuomaan rinnallaan olevista tyypeistä sen parhaan esiin. Kaikkea ei voi osata, eikä voikaan mutta se että osaa myöntää kun ei tiedä ja pyytää apua kun tarvitsee on tähdellistä.

Mä en kyllä mistään noista yllä olevista viesteistä saanut käsitystä että siellä puhuttiin "huippukoodarina" jostain sankarikoodaajasta joka vetäytyy pimeään koppiin energiajuoman ja pizzan kanssa ja tulee sieltä valmiin koodin kanssa ulos. Vaan sellaisesta joka uskaltaa code reviewssa pistättää purkkaspagetin uusiksi välittämättä siitä miten hankala se on selittää projektijohdolle, ja joka marssii whiteboardille kun pitää selittää tiimille miten se helvetin hankala kilke saadaan pelaamaan. Se tyyppi joka tekee tiimistä kuin tiimistä paremman, jonka tiimistä jokainen lähtee parempana koodarina kuin sinne meni.

 

[godzilla43]

Mä en kyllä mistään noista yllä olevista viesteistä saanut käsitystä että siellä puhuttiin "huippukoodarina" jostain sankarikoodaajasta joka vetäytyy pimeään koppiin energiajuoman ja pizzan kanssa ja tulee sieltä valmiin koodin kanssa ulos. Vaan sellaisesta joka uskaltaa code reviewssa pistättää purkkaspagetin uusiksi välittämättä siitä miten hankala se on selittää projektijohdolle, ja joka marssii whiteboardille kun pitää selittää tiimille miten se helvetin hankala kilke saadaan pelaamaan. Se tyyppi joka tekee tiimistä kuin tiimistä paremman, jonka tiimistä jokainen lähtee parempana koodarina kuin sinne meni.

Musta toi kuvaus kertoo just tuollaisesta "rockstar" koodarista joka aiheuttaa tuollaisen konfrontaatio-tilanteen. Eiköhän hyvä koodari olisi jo aiemmin ehdottanut/neuvonut purkkaspagetin tehnyttä koodaria.

 

[mopnex]

Mä en kyllä mistään noista yllä olevista viesteistä saanut käsitystä että siellä puhuttiin "huippukoodarina" jostain sankarikoodaajasta joka vetäytyy pimeään koppiin energiajuoman ja pizzan kanssa ja tulee sieltä valmiin koodin kanssa ulos. Vaan sellaisesta joka uskaltaa code reviewssa pistättää purkkaspagetin uusiksi välittämättä siitä miten hankala se on selittää projektijohdolle, ja joka marssii whiteboardille kun pitää selittää tiimille miten se helvetin hankala kilke saadaan pelaamaan. Se tyyppi joka tekee tiimistä kuin tiimistä paremman, jonka tiimistä jokainen lähtee parempana koodarina kuin sinne meni.

Myönnetään että siinä oli myös omaa laveaa tulkintaa, kuten nyt myös tuossa sinunkin vastauksessasi omasta pointista. Ketjussa ei nyt ehkä suoraan noin ilmaistuna asia ollut (viimeisimmissä viesteissä), alla kuitenkin esimerkkiä että 200te koodari koodailee (yksin) sellaisen softan mihin menee muilla (tiimillä) puolivuotta.

Olen samaa mieltä noista muista, eli tyyppi joka nostaa tiimin tasoa, ei hyväksy puolivillaista purkkaspagettia, on valmis keskustelemaan stakeholderien kanssa asiasta ja osaa selittää tiimille miten asiat saadaan tehtyä. Lisänä ehkä vielä se, että ei kuitenkaan oleta olevansa kaikessa paras, tai että oma ratkaisu on aina paras. Tuosta en ole mitenkään eri mieltä, enkä viestissäni muuta väittänytkään. Tuollaisia tyyppejä vaan on myös sen ns. "rockstara"-skenen ulkopuolella, ja tunnen monia. Jokaisella kerralla otan viereen tuollaisen kaverin kuin jonkun ylimielisen yksinkodastejlijan joka tekee mielestään aina kaiken paremmin, hieman harhaisesti.

Tiedan paljon koodareita jotka ovat yli 4 kertaa tehokkaampia kuin 50te koodarit. Eli ihan silla voi olla 200te koodari etta napputelee kuukaudessa sellaisen systeemin missa muilla menee puolivuotta.

 

[chrisekh]

Ihan selvennykseksi niin se 200t koodari siinä kuukauden aikana tekee ne muut scrumi velvollisuudet samalla kuin muukin tiimi. Se 200t mies vaan näkee headeristä kuinka sitä kirjastoa on tarkoitus käyttää koska on itsekkin joska tehnyt vastaavanlaisen kirjaston. 200t mies ei lue koodia rivi riviltä vaan näkee blokista päälle mitä siinä tehdää. 200t mies lisäksi tietää miksi joku asia tehdään ilman kommentteja. Bill gates sanoi että koodareissa on 1000 kertaisia eroja. Mitä minä muistelen omia junnu vuosia koulun jälkeen niin ei se 1000 kaukana ole. Silloin tietokone vei miestä eikä mies tietokonetta. Minä en ole 200t mies vielä. Ja saattaa olla etten koskaan olekkaan kun toivottavasti pääsen tästä C koodista eroon mutta silloin muut ovat jo paljon edellä,

 

[Zvona]

Olen ollut alalla nyt 20 vuotta ja en ole vielä tavannut superkoodaria, joka olisi edes 4x tehokkaampi kuin keskiverto-devaaja. Sen sijaan olen kyllä tavannut noita @mopnex kuvaamia rokkitähtiä, jotka luulevat olevansa 4x parempia.

Ja juu, ehkä sieltä tulee top notch -koodia testeineen päivineen 4x nopeammin kuin average joe:lta. Se on vain siinä, että UI/UX on taso excel herran vuonna 1995 ja funktionaalisen ohjelmoinnin kiekura-paradigmat ovat muulle tiimille täyttä hepreaa, jolloin niiden tulkitsemiseen käy seuraavalta devaajalta 4x hitaammin. Ja ei - tämä ei ole sen "huonomman" kehittäjän syy vaan nimenomaan sen cowboyn, joka kuvittelee kaikkien muidenkin suorittaneen huippuyliopiston huippuarvosanoin omaksuen kaiken ja polttaen kynttilää oman työn ohella molemmista päistä.

Mutta tähän voi toki vaikuttaa myös se seikka, että minun alani = web + mobiili, eikä siis ns. "oikeaa ohjelmointia".

 

[ravallo]

funktionaalisen ohjelmoinnin kiekura-paradigmat ovat muulle tiimille täyttä hepreaa

Hehe, funktionaalineidit Noi on ihan parhaita, varsinkin jos kuvittelevat olevansa vähän fiksumpia kuin ovatkaan, siinä passaillaan funktiota toiselle kunnes on tehty sellainen pachinko-kone ettei erkkikään selvitä mitä tapahtuu kun sinne pudotetaan arvo

No joo, rumasti naurettu, kyllähän tuollekin on paikkansa varsinkin UI puolella, mutta noissa vaan käy joskus niin että onpas opeteltu joku fiksu juttu ja sitten kun ainoa käytössä oleva työkalu on vasara, alkaa kaikki ongelmat näyttää nauloilta.

 

[mopnex]

Ihan selvennykseksi niin se 200t koodari siinä kuukauden aikana tekee ne muut scrumi velvollisuudet samalla kuin muukin tiimi. Se 200t mies vaan näkee headeristä kuinka sitä kirjastoa on tarkoitus käyttää koska on itsekkin joska tehnyt vastaavanlaisen kirjaston. 200t mies ei lue koodia rivi riviltä vaan näkee blokista päälle mitä siinä tehdää. 200t mies lisäksi tietää miksi joku asia tehdään ilman kommentteja. Bill gates sanoi että koodareissa on 1000 kertaisia eroja. Mitä minä muistelen omia junnu vuosia koulun jälkeen niin ei se 1000 kaukana ole. Silloin tietokone vei miestä eikä mies tietokonetta. Minä en ole 200t mies vielä. Ja saattaa olla etten koskaan olekkaan kun toivottavasti pääsen tästä C koodista eroon mutta silloin muut ovat jo paljon edellä,

Juu, ja en ole eri mieltä tästäkään - että on isojakin tuottavuuseroja. Tietyissä niche-jutuissa varmasti 1000 kertaisia eroja, tulee mieleen Commodoren historiikki ja siellä mm. C128, Amiga 1000 jne.. kehitysprojektit missä se kova luu osaa ratkoa ne ongelmat mihin ei ole kykyjä välttämättä kaikilla. Se ei tarkoita kuitenkaan sitä, etteikö noita kykyjä voisi hankkia.

Suomessa maksetaan noin lähtökohtaisesti aika keskivertopalkkoja osaamisesta riippumatta, etenkin konsulttipuolella. Olisihan se varmasti paikallaan että tekemisen ja osaamisen erot näkyisivät palkassa, mutta ei kukaan yksinään mitään projektia maaliin vie - tiimin työn tulos. Se että nostaa muita tiimiläisiä paremmaksi on mielestäni tärkeämpi ja oleellisempi asia kuin joku absoluuttinen paremmuus jossain spesifissä asiassa. Ellei nyt tosiaan suunnitella "uutta tietokonetta tyhjästä" case Amiga.

 

[chrisekh]

On muuten viela yksi tapa missa erottuu 200t konsultipuolella. Heita ei tahdo saada yksistaan vaan mukana tulee tulee junnuja samalla.

 

[finWeazel]

Mä ottaisin minä tahansa päivänä tiimillisen normiheppuja, jotka osaavat ja tykkäävät tehdä keskenään töitä yli sen, että olis yksi 100x kooderi+alamaisia. Se 100x heppu helposti vielä kaikenlisäksi vie muilta työnilon, jos ei ole sosiaalista ja tiimityötaitoa hallussa. On tullut sekä mukavia&järkeviä eikä niin mukavia 10x heppuja uranvarrella vastaan. Osalle porukasta paras paikka koodata on yksikseen kellarissa ja kaukana muista ihmisistä Joskus myös pitäisi miettiä tavista, joka sitä koodia ehkä myöhemmin ylläpitää ja jatkokehittää. Tosin ihan yhtälailla mulkkuja ja vähemmän mulkkuja ihmisiä on taviskoodereissa. En usko, että on 10x/100x heppujen ominaispiirre, että puuttuisi sosiaalisia taitoja. Sosiaalisten taitojen puute helposti korostuu, kun tyyppi saa 10x sen aikaan mitä muut. Poikkeus sääntöön pienet tuotefirmat, joissa 10/100x heppu saa koodata yksikseen kellarissa.

 

[chrisekh]

Ne 100x miehet voivat myos tuoda sen tyonilon. He katselevat peraan etta homma tehdaan mielekkaasti ja kukaan ei joudu hakkaamaan paataan seinaan mahdottoman ongelman edessa.

 

[finWeazel]

Voi pojat kun tyokaverit tykkaavat kun revin heidan 2 viikon tyonsa palasiksi code reviewssa ja sanon etta uusiksi meni. Joidenkin kanssa olen kieltanyt kaikenlaisen testaamisen ennen alustavaa code reviewia kun se on hukkaan heitettya aikaa jos koodi ei ole paasemassa masteriin. Jatkuva toiveeni on etta ihmiset tekisivat review pyynnon ihan aluksi niin olisi niin paljon helpompi opastaa oikealle tielle.

Kuulostaa melko mulkulta menolta ja myös siltä etteivät softaprosessitkaan ole kunnossa. Noissa tilanteissa olisi varmaan ihan hyvä olla päivittäiset erittäin lyhyet statuspalaverit ja siihen perään jutella ongelmakohdista(jos niitä on), että saadaan koodi tehtyä nopeammin ja tyyppi oppii heti eikä tule mitään 2vk työtä vessanpöntöstä alas putken loppupäässä efektiä. Pari kertaa tuon 2vk töitä ja vessanpöntöstä alas tempun toistaa niin uhri vittuuntuu ja hakee uuden työpaikan, missä on fiksummat toimintatavat ja missä saa paremman mentorin opettamaan asioiden tekemistä. Voisi olla myös syytä miettiä, että josko niitä committeja voisi saada pienempina palasina arvosteluun ja sisään.

 

[chrisekh]

No ei se koodi status miiteissa nay. Ja se sita initial pull requa ei millaan haluta tehda kun halutaan leikkia silla koodilla etta on joku varmuus etta se pelaa. Been there done that. Et sa nyt voi pakottaa aikuista ihmista sita code reviewia aloittamaan vakisin ja ei oikein viitsi niskankaan taakse menna. Monta kertaa pyytanyt tupakka-askin kanteen jotain hahmotelmaa kuinka ajattelee tehda niin sita nyt varmasti ole saanut ennenkuin koodi on valmis. Kuinka te hoitaisitte asian? Onko se ratkaisu etta koodi sisaan ja korjataan myohemmin?

 

[finWeazel]

No ei se koodi status miiteissa nay. Ja se sita initial pull requa ei millaan haluta tehda kun halutaan leikkia silla koodilla etta on joku varmuus etta se pelaa. Been there done that. Et sa nyt voi pakottaa aikuista ihmista sita code reviewia aloittamaan vakisin ja ei oikein viitsi niskankaan taakse menna. Monta kertaa pyytanyt tupakka-askin kanteen jotain hahmotelmaa kuinka ajattelee tehda niin sita nyt varmasti ole saanut ennenkuin koodi on valmis. Kuinka te hoitaisitte asian? Onko se ratkaisu etta koodi sisaan ja korjataan myohemmin?

Ajaisin sisään esimerkisi agile-prosessia kuten scrumm. Taskit kuvataan riittävän tarkasti backlogia kasatessa. Jos toteutettava ominaisuus on epäselvä se selvitetään ennen sprinttiin mukaanottamista. Päivittäin on lyhyt statuspalaveri. Jos on ongelmia niin statuspalaverin jälkeen pienemmällä porukalla sumplitaan ongelmakohdat. Jos tyyppi on uusi niin osana prosessia mentori opettaa oikeille toimintatavoille kuten sopivantason suunnitelman&dokumentaation tekemiseen + wip koodin puskemiseen päivittäin talteen serverille. Jos ei muun syyn vuoksi pusketa päivittäin niin vähintään sen takia, että jos työkone hajoaa niin on työt tallessa. Jos tulee UrhoMattia niin ne syyt analysoidaan mitkä johtivat siihen ja parannetaan toimintatapoja niin ettei samasta syystä tulee UM:aa uudestaan ja uudestaan ja uudestaan.

Parikoodaus on ihan hyvä juttu yhtenä vaihtoehtona, että homma saadaan lähtemään eteenpäin oikealla tavalla. Yksi vaihtoehto on myös jotenkin löytää tapa palastella työtä pienempiin kokonaisuuksiin ettei joku tee viikkokausia töitä ja sitten tulee UM lopussa.

Jos syy päivittäisen puskemisen välttämiseen serverille on esim. agressiivinen palaute ja vittuilu niin kehitetään myös sitä palautetta antavaa tahoa positiivisempaan suuntaan. Joku syyhän siihen on ettei uskalleta/haluta päivittäin puskea työtä esille. Jos se syy on muiden antama vittuilu niin puututaan siihen vittuiluun. Jos kyseessä on jatkuva kädettömyys suunnassa tai toisessa niin vakava keskustelu on paikallaan. Jos meno ei parane niin on aika antaa potkut. Joskus tulee virherekryjä.

edit. Lisätään nyt vielä, että ne asiat mitkä voidaan automatisoidaan ettei koodikatselmoinneissa tarvi esimerkiksi keskustella välilyönneistä(clang-tidy) tai apien dokumentoinnista(doxygen). Joistain asioista on myös hyvä sopia ihan kirjallisesti dokumentaatiossa niin kaikki tietävät mitä odotetaan esim. koodin dokumentoinnin/testauksen/... osalta eikä tarvi sitten katselmoinnissa väitellä asiasta.

 

[chrisekh]

Jaa niin taytyisi niita brancheja kayda katselemassa ennen pull requa. Ei oikein riita aika kaivelemaan toisten brancheja servulta. Yleensa se vittuile alkaa vasta siina kohtaa kun vangataan siita onko jokin ratkaisu hyva vai huono. Harvemmin olen reviewien ensimmaisissa viesteissa nahnyt kettuilua.

 

[finWeazel]

Jaa niin taytyisi niita brancheja kayda katselemassa ennen pull requa. Ei oikein riita aika kaivelemaan toisten brancheja servulta. Yleensa se vittuile alkaa vasta siina kohtaa kun vangataan siita onko jokin ratkaisu hyva vai huono. Harvemmin olen reviewien ensimmaisissa viesteissa nahnyt kettuilua.

Isommat valitut ratkaisut voisi sopia ennen sprintin aloittamista tai ensimmäisenä taskina valita ja hyväksyttää valittu lähestymistapa. Eihän sitä taskin kokoa/valmistumista sprintissä voi edes tietää millään tasolla varmaksi, jos asiaa ei ole pureskeltu etukäteen. Jonkun olisi hyvä keskittyä siihen, että kokonaisuus pysyy kasassa vaikka se tarkoittaakin sille hepulle vähemmän koodausaikaa. Isommissa organisaatioissa seniorin rooli voi olla paljon sitä, että autetaan muita ja itse ei saa tehdä enää niin paljoa koodia.

Esimerkiksi mun työpanos arvioidaan sen pohjalta mikä vaikutus mun tekemisillä on muiden työhön ja etenkin muiden työhön oman tiimin ulkopuolelta. Seniorin työpanos monistuu muiden ihmisten kautta. Omassa työssä pitää olla valmis mentoroimaan muita ihmisiä positiivisella tavalla. Yksin voi tehdä sen pienen palasen. Jos saa 10 tai 20 tai 50 ihmistä tekemään vähän paremmin työtä&työskentelemään yhdessä niin seniorin työpanos kertautuu useamman ihmisen kautta. Työpanoksen kertautuminen jatkuu viikkojen, kuukausien ja vuosien aikana, jos porukka saadaan puhaltamaan yhteen hiileen tehokkaasti. Tähän vois kertoa latteuden, että jos haluaa edetä nopeasti niin mene yksin, jos haluat kauas niin mene porukassa.

Suosittelen varauksetta tätä kirjaa: Leadership and Self-Deception

 

[Bladekill]

Ei tuollaiset 200k tyypit oikein pysty konsulttipuolella tai muutenkaan monissa "perus" web projekteissa tuottamaan hintansa edestä arvoa. Useimmissa projekteissa vain pitää saada se ecom tjsp softa liveksi ja sillä selvä. Onko se sitten tehty aivan täydellisellä Google-tason toptier arkkitehtuurilla kirsikoiden kera vai ei on aika toissijaista kun softaprojekti on kuitenkin vain investointi ja sen arvo mitataan asiakkaiden kautta. Jos tyyppi maksaa 300-400% enemmän, mutta hänen vaikutus ROI:n on n. 0-10% niin vituiks meni. Samoiten jos softa uudelleenkirjoitetaan 2v päästä tai suoraan tapetaan niin se täydellinen codebase ja arkkitehtuuri joka palvelee vaikka seuraavat 10v menee harakoille.

Huomattavasti tärkeämpää edellämainitun tapaisissa projekteissa on se ettei mukana ole paskoja devaajia kuin se onko projektissa "perus senior dev" vai joku ylijumala koodijeesus. Oikeasti monimutkaiset, isot ja pitkäikäiset tuotteet sitten erikseen kuten Google haku, iOS, asejärjestelmät, Netflix jne.

 

[chrisekh]

Ei ole nyt puhe etta 200k oli mikaan super arkkitehti vaan esimerkiksi koodaa laiteajurit uuteen MCU kuukaudessa ja koodi on sellaista mita on helppo yllapitaa. Ja se ei tarkoita etteiko se olisi kuukautta mukana scrumissa ja tekemassa PR viikoittan. Ne vaan on 4 kertaa tehokkaampia kuin rivikoodarit. Oliko kuukausi missa ajassa Torvalds koodasi Gitin _Core_ komponentit. Sanoisin etta peruskoodareilta menisi 12kk moiseen vaikka minulla nyt ei ole edes kasitysta siita mita on gitin gore.

 

[zepi]

Palkkaus kertoo omasta mielestäni enemmän työpaikan sijainnista kuin henkilön ominaisuuksista. Tai ainakin vähintään yhtä paljon.

100k bruttoliksainen koodari / devops / mikälie voi tarkoittaa mitä tahansa täysin 0-päivää työkokemusta märkäkorvan (Zürich) ja Superkova osajaa (Bukarest / Kuopio) väliltä.

Tämä on tietty hassua näin 100% etätöiden aikana, mutta niin se vaan menee. Jos perus-inssi vaihtaa syrjäkylän konttorilta Helsinkiin ja sieltä edelleen Müncheniin, Amsterdamiin tai Zürichiin, niin bruttoliksa voi helposti 2.5 kertaistua ilman, että työtehtävät muuttuvat mihinkään.

 

[Bertta]

Ei ole nyt puhe etta 200k oli mikaan super arkkitehti vaan esimerkiksi koodaa laiteajurit uuteen MCU kuukaudessa ja koodi on sellaista mita on helppo yllapitaa. Ja se ei tarkoita etteiko se olisi kuukautta mukana scrumissa ja tekemassa PR viikoittan. Ne vaan on 4 kertaa tehokkaampia kuin rivikoodarit. Oliko kuukausi missa ajassa Torvalds koodasi Gitin _Core_ komponentit. Sanoisin etta peruskoodareilta menisi 12kk moiseen vaikka minulla nyt ei ole edes kasitysta siita mita on gitin gore.

Torvalds ei ole hyvä koodari sen vuoksi, että pystyi koodaamaan git:n pohjan kuukaudessa, vaan siksi, että hän tiesi mitä oli tekemässä ja se mitä hän oli tekemässä oli innovatiivista ja uudenlaista.

Torvaldsin 1000000x -kertainen suoritus tulee siitä, että kukaan muu ei ollut edes yrittämässä ”git”:n koodausta.

 

[finWeazel]

Torvalds ei ole hyvä koodari sen vuoksi, että pystyi koodaamaan git:n pohjan kuukaudessa, vaan siksi, että hän tiesi mitä oli tekemässä ja se mitä hän oli tekemässä oli innovatiivista ja uudenlaista.

Torvaldsin 1000000x -kertainen suoritus tulee siitä, että kukaan muu ei ollut edes yrittämässä ”git”:n koodausta.

Lisätään tähän vielä muiden kautta monistunut työpanos. Jos git:in ja linuxin ympärille ei olisi syntynyt aktiivisia yhteisöjä niin torvaldsin koodausten arvo olisi oleellisesti vähäisempi.

 

[zepi]

Niin - ja lisätään vielä se, että ainakin periaatteessa työnantajan näkökulmasta palkan pitäisi määräytyä sen perusteella, että millä rahalla henkilön saa korvattua riittävän hyvällä korvikkeella.

Usein tuote ei voi ulkoisista rajoitteista johtuen skaalata tiettyä koko isommaksi, jolloin koodin laatu tai featureiden toteutusnopeus ja/tai ylläpidon helpottuminen ei voi tuottaa jotain kiinteää summaa suurempaa hyötyä ja tällöin on hyödytöntä pitää ”äärettömän hyvää” duunaria töissä - seuraavaksi paras piisaa.

 

[nbzero]

Niin - ja lisätään vielä se, että ainakin periaatteessa työnantajan näkökulmasta palkan pitäisi määräytyä sen perusteella, että millä rahalla henkilön saa korvattua riittävän hyvällä korvikkeella.

Usein tuote ei voi ulkoisista rajoitteista johtuen skaalata tiettyä koko isommaksi, jolloin koodin laatu tai featureiden toteutusnopeus ja/tai ylläpidon helpottuminen ei voi tuottaa jotain kiinteää summaa suurempaa hyötyä ja tällöin on hyödytöntä pitää ”äärettömän hyvää” duunaria töissä - seuraavaksi paras piisaa.

varmasti näin, ja pitää itkeä koko matka pankkiin nykyisissä töissä, joissa maksetaan tuplapalkka. viime duuneissa piti paikkailla muiden virheitä ylitöillä (joita ei makseta, vaan korvataan vapaana, jota ei voi koskaan saada) ja olla aina siltä varalta käytettävissä, että tarvitaan joku lukutaitoinen ja pätevä paikalle.

 

[Kernomas]

Paljonkohan voisi olla palkka Scrum Masterilla, joka ei tule devaustiimistä, vaan on ulkopuolinen henkilö? Tarkoitus myös ilmeisesti toimia osittain Product Ownerina. Eli siis asiakasrajapinnassa toimimista ja fasilitointia yms.

 

[paasi]

Paljonkohan voisi olla palkka Scrum Masterilla, joka ei tule devaustiimistä, vaan on ulkopuolinen henkilö? Tarkoitus myös ilmeisesti toimia osittain Product Ownerina. Eli siis asiakasrajapinnassa toimimista ja fasilitointia yms.

Kokemus määrittelee paljon ja epäilemättä sijainti. Pk-seudullakin haitari lienee suuri, 4-6ke semmonen keskiverto ainakin konsulttina.

 

[chrisekh]

Kuulostaa niin erikoiselta etta Scrum masteri ja owneri olisi samalla tyypilla. Onkuin olisi paaluottamusmies ja toimitusjohtaja sama. Scrum master tarkein tehtava minusta on kytata managmenttia ja owneria etta sprintti on alussa maaritelty ja mahdolliset muutokset hoidetaan niin etta kaikki ovat tyytyvaisia. Kirsikikkana kakun paalla ja minusta raskaimpana tehtavana on saada porukka retroissa avautumaan ja hakemaan keinoja saada hommaa mukavammaksi. Ei devaavan Scrum masterin on kylla vaikea huomata sita milloinka owneri ja management modaavat vaatimuksia kesken sprintin. Joskun olen kaynyt managementtia hatistelemassa pois devaajien tykoa ja kehottanut tulemaan takaisin ownerin kanssa uusien requjen kanssa joita voidaan sitten tiimissa hinnoitella.

 

[Bladekill]

Kuulostaa niin erikoiselta etta Scrum masteri ja owneri olisi samalla tyypilla. Onkuin olisi paaluottamusmies ja toimitusjohtaja sama.

Omien kokemuksieni pohjalta on kohtuu yleistä että monissa ei-teknisissä firmoissa nuo saappaat täyttää sama henkilö (PO, PM, Release manager jne. koska halutaan säästää). Monesti on vain PO ja Scrum Masterin tehtävät ikään kuin jaetaan lead devaajan ja PO:n kesken.

Ei devaavan Scrum masterin on kylla vaikea huomata sita milloinka owneri ja management modaavat vaatimuksia kesken sprintin. Joskun olen kaynyt managementtia hatistelemassa pois devaajien tykoa ja kehottanut tulemaan takaisin ownerin kanssa uusien requjen kanssa joita voidaan sitten tiimissa hinnoitella.

Ei tuo välttämättä vaadi mitään devaamisosaamista, mutta SM:n täytyy kyllä ymmärtää miten softakehitys/agile/scrum toimii ja mitä enemmän kokemusta aiheesta on niin sitä parempi.

 

[chrisekh]

Omien kokemuksieni pohjalta on kohtuu yleistä että monissa ei-teknisissä firmoissa nuo saappaat täyttää sama henkilö (PO, PM, Release manager jne. koska halutaan säästää). Monesti on vain PO ja Scrum Masterin tehtävät ikään kuin jaetaan lead devaajan ja PO:n kesken.

Ainoa scrum masterin tehtävä jonka voin antaa PO on neukkareiden varaaminen kokouksiin. Mutta mitä muita tehtäviä PO voisi antaa? Se on ihan kuin pääluottamies mies ja TJ jakaisivat tehtäviä.

Tällä kuvalla juuri motivoin meidän Scrum masteria kun huomasin että Chief vie speksiä suoraan devaajalle ja devaaja valittaa kun ei ymmärrä.

CE

 

[chrisekh]

Olen kerran ollut tiimissä jossa PO ja SM oli sama henkilöä ja ei niistä sprinteistä tullut yhtään mitään koska sprintin sisältö eli koko ajan. Ainoa vaihtoehto oli itse alkaa SM vaikka se on ihan paska nakki että saatiin sprintit kuntoon ja pidettyä retroja joista lähti vaatimuksia myös ulkopuolelle.

 

[paasi]

Näihin löytyy kaikenlaisia virityksiä 2 SMstä edellä kuvattuihin skenarioihin. Olisi hyvä. Jos aihetta olisi laajemmin opiskeltu organisaatiossa tai sillä SMllä olisi aikaa koutsata organisaatiota. Liian usein siellä missä tekeminen ei tule luonnostaan, tuppaa panostusolemaan luokkaa 0.25FTE hoitamaan pakollisen byrokratian.

 

[Randomizer]

Monesti taitava koodari tai edes taitava tiimi ei toimi hyvin jos devaus tiimin ympärillä hommat toimii huonosti. Esim. kankea interface infraan, compliance säännöt, Segregation of Duties voi olla iso este tehokkaalle kehittämiselle. Toinen minkä olen vasta myöhemmin uralla huomannut on että jos agilemenetelmiä käytetään väärin (tai vaihtoehtoisesti oikein, jolla päinvastainen vaikutus), se voi vaan häiritä tekemistä.

Todella paljon törmää myös tuohon "ei uskalla deployata, saattaa rikkoa jotakin", joka on aina huono merkki. JA minun mielestäni Scrummarin pitäisi aina olla keskitetty rooli, eli sama tyyppi ei koodaa päivätyökseen.

 

[chrisekh]

Tuo devaus tiimin ympärillä olevat paskuudet on asioita jotka täytyy löytää retrossa ja niitä täytyy saada painostettu kuntoon. Ei kukaan tajua niiden haittaavan jos ei rummuta.

 

[Kernomas]

Hyvää pohdintaa ja näkemyksiä, kiitos siitä. Tosiaan minulle on tarjottu Scrum Masterin roolia konsulttitalosta, jossa siis tehdään useille eri asiakkaille softaprojekteja samaan aikaan. Scrumia on siellä käytetty aiemminkin, mutta kuulemma jonkun pitäisi ottaa "hallittu kaaos" haltuun. Eli en nyt ole ihan varma, että kuka tuota roolia on aiemmin hoitanut, vai onko kukaan. Kuulostaisi kyllä oudolta, jos siinä ei ketään ole aiemmin ollut. Ja tosiaan PO:n rooli ilmeisesti olisi pääosin toisen henkilön, mutta minulta toivottiin myös siihen jonkinlaista osallistumista.

Leanista on käytännön kokemusta, Scrum ja Agile on teoriatasolla tuttuja, mutta käytännön kokemus puuttuu. Toki osinhan noissa on samoja periaatteita. Toisaalta kyllä tehtävä kiinnostaa, kun olisi ihan erilaista hommaa, mitä olen aiemmin tehnyt, mutta toisaalta mietityttää, että millaiseen sekasotkuun olen lähdössä mukaan...

 

[paasi]

Jos korvaus on kohdillaan ja talo on suht. järkevä niin tuosta saanee hyvää oppia!

 

[Randomizer]

Hyvää pohdintaa ja näkemyksiä, kiitos siitä. Tosiaan minulle on tarjottu Scrum Masterin roolia konsulttitalosta, jossa siis tehdään useille eri asiakkaille softaprojekteja samaan aikaan. Scrumia on siellä käytetty aiemminkin, mutta kuulemma jonkun pitäisi ottaa "hallittu kaaos" haltuun. Eli en nyt ole ihan varma, että kuka tuota roolia on aiemmin hoitanut, vai onko kukaan. Kuulostaisi kyllä oudolta, jos siinä ei ketään ole aiemmin ollut. Ja tosiaan PO:n rooli ilmeisesti olisi pääosin toisen henkilön, mutta minulta toivottiin myös siihen jonkinlaista osallistumista.

Leanista on käytännön kokemusta, Scrum ja Agile on teoriatasolla tuttuja, mutta käytännön kokemus puuttuu. Toki osinhan noissa on samoja periaatteita. Toisaalta kyllä tehtävä kiinnostaa, kun olisi ihan erilaista hommaa, mitä olen aiemmin tehnyt, mutta toisaalta mietityttää, että millaiseen sekasotkuun olen lähdössä mukaan...

Jos sä teet hyvin SM hommat, devarit ja tiimit ovat erittäin kiitollisia. Minusta SM on aliarvostettu rooli ja jos sen hoitaa hyvin, se auttaa kaikkia.

 

[Ratsia]

Yhtäkkiä voikin matkustella kaikkialle taksilla, voi syödä jatkuvasti ulkona ja mennä skyline torneihin drinkeille kaverien kanssa, ostaa Applen ylihinnoiteltua romua ja silti rahaa jää ikään kuin vahingossa säästöön. Vaikka Suomessa oli top 10% tienaajista niin silti räntäsateessa sai marssia Alepaan laskemaan lantteja ja jos vähänkään yritti elää elämää niin mitään ei jäänyt säästöön.
...
Nykyisellää Shanghaissa/Pekingissä/Shenzhenissä palkat tosiaan ovat täysin kilpailykykyisiä Suomen kanssa. Sanoisin että varianssi on kuitenkin isompi. Juniordevaajien palkat saattavat lähtä 1200e paikkeilta, mutta senior devaajat nostavat n. 4000-8000e/kk ja sitten kokeneemmat arkkitehdit ja tekniset johtajat saattavat helposti netota 10-30ke/kk. Suomessa muut edut tosin ovat yleensä keskimäärin parempia (kulttuurisetelit, puhelin, vuosilomat, work/life balance jne.) Tosin sitten jos tekee töitä Googlelle, Applelle, MS, AWS tai muille Piilaakson jäteille/vastaaville niin sekä edut että palkat jättävät Suomen jälkeensä.

Onnistuit kyllä triggeröimään ja pahasti, harvoin tulee yhtä oksettavaa kirjoitusta vastaan. Kiinassa elää n 600 miljoonaa ihmistä alle vitosella päivässä, ja taksisuhari tai skylinebaarin (lol) kyyppari ei varmaan tienaa paljoa enempää.
Vaikken olekaan mikään suuri humanisti, niin meikäläisen moraali ei taipuisi työskentelemään yhdellekään noista pahan akselin firmoista. Amazon yrittää täyttää koko maapallon joutavalla paskalla samalla kun miljoona firman suharia yrittää tienata leipäänsä jonkinlaisessa gig economyssä ja samaan aikaan applen komponenttitehtaan työntekijät hyppivät katolta kun ei enää kasetti kestä. Mainitsemiesi firmojen pääsubstanssi on veronkierto ja ihmisten orjuuttaminen (huawein tapauksessa kirjaimellisesti), mut pääasia on että Dr. Evil pääsee minuutiksi avaruuteen, ja sulle riittää sateenkaaridrinksuja. Jatka samaan malliin, mut pysy pliis siellä kiinassa.

 

[dropadrop]

Onnistuit kyllä triggeröimään ja pahasti, harvoin tulee yhtä oksettavaa kirjoitusta vastaan. Kiinassa elää n 600 miljoonaa ihmistä alle vitosella päivässä, ja taksisuhari tai skylinebaarin (lol) kyyppari ei varmaan tienaa paljoa enempää.
Vaikken olekaan mikään suuri humanisti, niin meikäläisen moraali ei taipuisi työskentelemään yhdellekään noista pahan akselin firmoista. Amazon yrittää täyttää koko maapallon joutavalla paskalla samalla kun miljoona firman suharia yrittää tienata leipäänsä jonkinlaisessa gig economyssä ja samaan aikaan applen komponenttitehtaan työntekijät hyppivät katolta kun ei enää kasetti kestä. Mainitsemiesi firmojen pääsubstanssi on veronkierto ja ihmisten orjuuttaminen (huawein tapauksessa kirjaimellisesti), mut pääasia on että Dr. Evil pääsee minuutiksi avaruuteen, ja sulle riittää sateenkaaridrinksuja. Jatka samaan malliin, mut pysy pliis siellä kiinassa.

Suomen köyhimmät tuella elävätkin putoavat tohon laariin. Miten se, että elää kiinassa on tuon ongelman kannalta eri kuin että elää länsimaassa?

 

[Takaisku]

Scrumia on siellä käytetty aiemminkin, mutta kuulemma jonkun pitäisi ottaa "hallittu kaaos" haltuun.

Kaikkien hienojen prosessien vastapainoksi voin kertoa kuinka homma hoituu isossa amerikkalaisessa tuotetalossa. Teemme omaa rautaa ja siihen päälle softaa jota myydään pakettina suoraan kuluttajille. Joka ikinen tuote on tehty ilman kunnollista arkkitehtuurisuunnittelua mutta kukaan ei uskalla tehdä isompia korjauksia koska jotain voi mennä (enemmän) rikki. Minkäänlaisia testejä koodille ei luonnollisestikaan ole, yksi tiimi kehitysmaassa testaa manuaalisesti minkä ehtii. Jokaista tuotetta vetää yksin joku guru jolla ei tietenkään ole aikaa dokumentoida mitään tai opastaa muita koodiorjia aiheeseen.

Tästä kaaoksesta seuraa se että joka tuotteen softat menee roskiin alle viidessä vuodessa jonka jälkeen sama "prosessi" toistetaan. Eri tuotteiden ohjelmistoilla on paljon päällekkäisyyksiä mutta mitään uudelleenkäytettäviä komponentteja ei ole. Mutta koska firmalla menee hyvin, rahaa tulee ikkunoista ja ovista ja maksimibonukset tulee tilille kvartaaleittain niin ketään ei kiinnosta korjata epäkohtia

 

[nbzero]

Kaikkien hienojen prosessien vastapainoksi voin kertoa kuinka homma hoituu isossa amerikkalaisessa tuotetalossa. Teemme omaa rautaa ja siihen päälle softaa jota myydään pakettina suoraan kuluttajille. Joka ikinen tuote on tehty ilman kunnollista arkkitehtuurisuunnittelua mutta kukaan ei uskalla tehdä isompia korjauksia koska jotain voi mennä (enemmän) rikki. Minkäänlaisia testejä koodille ei luonnollisestikaan ole, yksi tiimi kehitysmaassa testaa manuaalisesti minkä ehtii. Jokaista tuotetta vetää yksin joku guru jolla ei tietenkään ole aikaa dokumentoida mitään tai opastaa muita koodiorjia aiheeseen.

Tästä kaaoksesta seuraa se että joka tuotteen softat menee roskiin alle viidessä vuodessa jonka jälkeen sama "prosessi" toistetaan. Eri tuotteiden ohjelmistoilla on paljon päällekkäisyyksiä mutta mitään uudelleenkäytettäviä komponentteja ei ole. Mutta koska firmalla menee hyvin, rahaa tulee ikkunoista ja ovista ja maksimibonukset tulee tilille kvartaaleittain niin ketään ei kiinnosta korjata epäkohtia

tuttua huttua. ootko yrittänyt esim. tuota testausta ujuttaa uusiin projekteihin?

 

[zepi]

Kaikkien hienojen prosessien vastapainoksi voin kertoa kuinka homma hoituu isossa amerikkalaisessa tuotetalossa. Teemme omaa rautaa ja siihen päälle softaa jota myydään pakettina suoraan kuluttajille. Joka ikinen tuote on tehty ilman kunnollista arkkitehtuurisuunnittelua mutta kukaan ei uskalla tehdä isompia korjauksia koska jotain voi mennä (enemmän) rikki. Minkäänlaisia testejä koodille ei luonnollisestikaan ole, yksi tiimi kehitysmaassa testaa manuaalisesti minkä ehtii. Jokaista tuotetta vetää yksin joku guru jolla ei tietenkään ole aikaa dokumentoida mitään tai opastaa muita koodiorjia aiheeseen.

Tästä kaaoksesta seuraa se että joka tuotteen softat menee roskiin alle viidessä vuodessa jonka jälkeen sama "prosessi" toistetaan. Eri tuotteiden ohjelmistoilla on paljon päällekkäisyyksiä mutta mitään uudelleenkäytettäviä komponentteja ei ole. Mutta koska firmalla menee hyvin, rahaa tulee ikkunoista ja ovista ja maksimibonukset tulee tilille kvartaaleittain niin ketään ei kiinnosta korjata epäkohtia

Vastaavasti on tuhansia projekteja / firmoja joissa tehdään asiat vimpan päälle oikein, mutta tuote ei myy ja firma kuopataan parin vuoden päästä ja koodia ei käytä kukaan ikinä…

Turvat kiinni siellä koodaripuolella, setä alkaa nyt tehdä massia sillä teidän softalla.

 

[Takaisku]

tuttua huttua. ootko yrittänyt esim. tuota testausta ujuttaa uusiin projekteihin?

En todellakaan, sitähän joutuu vielä itse tekemään jotain asian eteen. Heiluttelen firmassa käsiä 3-4 vuotta ja aloitan vapaaherran elämän
Pomo kyllä pyysi tekemään asioita softan laadun parantamiseksi mutta raha on tehnyt minut laiskaksi. Aina palkkapäivänä tai optioiden erääntyessä yritän jotain saada aikaan ettei ole niin syyllinen olo

 

[Jeesbox]

Jokaista tuotetta vetää yksin joku guru jolla ei tietenkään ole aikaa dokumentoida mitään tai opastaa muita koodiorjia aiheeseen.

Tosta ne (joidenkin) kovat palkatkin johtunee, sillä aina voi vedättää palkkaa suuremmaksi, jos on ainut, joka tajuaa, miten koodi toimii - kunnes tulee päivä, kun kaikki kirjoitetaan uudestaan.

 

[chrisekh]

Olen taysin erimielta. Paras tapa saada enemman palkkaa on pitaa osaamistaito sellaisena etta tyopaikan vaihto en helppoa. Hautausmaat ovat korvaamattomia taynna. Aina knowledge mista voi olla hyotya on se etta tietaa keta kaikkia esimiehet paneskelevat.

 

[zepi]

Paras lääke saada hyvää palkkaa on tehdä itsestään vaikeasti korvattava joko osaamisen tai muun knowledgen myötä.

Varmempaa on muuttaa paikkaan missä maksetaan enemmän.

Tuo itsensä tarpeelliseksi tekeminen kun ei onnistu aina - yhtään fiksumpi manageri äkkää homman ja varmistaa, ettei sitä pääse tapahtumaan.

—
Taitojen ja tietojen kartuttaminenkin on joskus hankalaa. Jos backlogi on 100% täynnä legacyä ja aikaa uuden opetteluun ei ole (pomo efektiivisesti kieltää uuden opettelun) ja kotona on kaksi lasta + muutakin tekemistä kuin omalla ajalla opettelu, niin jumissa ollaan.

Muutenkin ohje ”supermieheksi” muuttumisesta on vähän kyseenalainen. ”Kantsii olla neurokirurgi jos haluaa tienata paljon”. Jee, kiitos neuvosta. Entäs jos ÄOjä ja jaksaminen ei riitä sinne asti pääsemiseen?

 

[dropadrop]

Paras lääke saada hyvää palkkaa on tehdä itsestään vaikeasti korvattava joko osaamisen tai muun knowledgen myötä.

Oon useamman kerran nähnyt, kun näitä tyyppejä on poistettu YT’eissä. Hirveä riski, ja vaikeita tuurata lomilla kun pimittävät liikaa tietoa että olisi helppo korvata.

Mulla on aina ollut täyain päinvastainen strategia. Olen pyrkinyt tekemään itsestäni turhan, ja etsinyt sen jälkeen mielenkiintoisempaa tekemistä. Tuossa yleensä tehostuu koko tiimin / osaston toiminto, ja aina löytyy saman talon sisältä uusia haasteita - mieli pysyy virkeänä.

 

[Bladekill]

Onnistuit kyllä triggeröimään ja pahasti, harvoin tulee yhtä oksettavaa kirjoitusta vastaan.

Kannattaa ehkä laittaa jäitä hiukan hattuun jos triggeröityy jostain aivan normaalista tekstistä.

Kiinassa elää n 600 miljoonaa ihmistä alle vitosella päivässä, ja taksisuhari tai skylinebaarin (lol) kyyppari ei varmaan tienaa paljoa enempää.

Ihan ensin täytyy kysyä, että miten tämä milläänlailla liittyy IT-alan työpaikkoihin tai käytyyn keskusteluun? Päätit vai sattumalta sylkeä jotain ajatuksen virtaa tähän?
Toiseksi selvästikään et tiedä ollenkaan mistä puhut. Koko Itä-Kiina ja monet muutkin merkittävät alueet kuten Yunnan, Sichuan jne. ovat vaurastuneet talouskasvun mukana ja esim. Shanghaissa, Shenzhenissä jne. kahvilan työntekijät, hotellivirkailijat, vaatekaupan myyjät ja muut duunarit ilman erikoistaitoja nettoavat 800-2000e/kk. Tähän sitten kun lasketaan paikallinen hintataso mukaan ja nettopalkka muutetaan ostovoimaksi niin he tienaavat paremmin kuin suomalainen vastaava.

Vaikken olekaan mikään suuri humanisti, niin meikäläisen moraali ei taipuisi työskentelemään yhdellekään noista pahan akselin firmoista. Amazon yrittää täyttää koko maapallon joutavalla paskalla samalla kun miljoona firman suharia yrittää tienata leipäänsä jonkinlaisessa gig economyssä ja samaan aikaan applen komponenttitehtaan työntekijät hyppivät katolta kun ei enää kasetti kestä. Mainitsemiesi firmojen pääsubstanssi on veronkierto ja ihmisten orjuuttaminen (huawein tapauksessa kirjaimellisesti), mut pääasia on että Dr. Evil pääsee minuutiksi avaruuteen, ja sulle riittää sateenkaaridrinksuja. Jatka samaan malliin, mut pysy pliis siellä kiinassa.

Ensinnäkään Applella ei ole tehdasta täällä vaan ne ovat aasialaisten alihankkijoiden tehtaita, Amazonin tuotekauppa on aivan eri asia ja yritys kuin AWS ja lopuksi Huaweista en puhunut sanallakaan missään vaiheessa.

Jotenkin ironista itkeä köyhyydestä ja sen jälkeen valittaa näistä jenkkifirmoista kun tosiasia on se että länsimaalaiset kapitalistiset korporaatiot ja heidän investointinsa ovat se syy miksi sadat miljoonat ihmiset ovat Kiinassa päässeet pois köyhyydestä ja nyt miettivät lähinnä sitä minkä värisen Teslan tai iPhonen laittavat. Sinun kaltaistesi "maailmanparantaja marxistien" takia taas vanhemmat joutuivat aikoinaan myymään toisen lapsensa prostituutioon ja syömään toisensa ruuanpuutteen takia ja tätä vahinkoa saadaan todennäköisesti korjata vielä ainakin seuraavat 100v.

Rahaa voi yrittää toki lapata pohjattomaan hyväntekeväisyyskaivoon mistä seuraa vain ikuinen riippuvuussuhde lahjoittajan ja vastaanottajan välille ja mikään ei muutu kuten on Afrikassa nähty tai sitten voi investoida maahan ja alkaa käymään kauppaan heidän kanssaan ja hupsista...köyhyys muuttuu rikkaudeksi. Ne skylinebar drinkit, taksimatkat ja ylipäätään mikä tahansa paikallisen talouden tuottaman palvelun/tuotteen ostamisen on se merkittävin humaanein teko minkä voi tehdä. Eikä nuo ole mitään rikkaiden expattien yksinoikeuksia vaan aivan normaaleja asioita mitä uusi kiinalainen keskiluokka itse ostaa ja kuluttaa joka päivä.

 

[mt247]

Arvostaako softapuolen työnantajat sysadmin/ylläpidon osaamista infrapuolelta windows/linux palvelimien sekä AWSn/Azuren jne. parista? Alkanut houkuttelemaan vaihto softapuolelle, kun alkanut puuduttamaan vuorotyö ja se ettei ole mahdollista etätöihin.