IT-alan työpaikat

[emagdnim]

Todella jees saada Reaktorilta haastattelukutsu. Tuon saamiseen tosin meni noin kuukausi (hakemus lähetetty joulukuun lopulla, eli ota pois joululomia, ja yhteydenotto tuli about helmikuussa), joten tulkitsen että en ollut ensimmäisten, sopivimmiksi arvioitujen joukossa. Enpä myöskään olisi ennustanut, että Vincitin haastattelussa levitellään käsiä jo melkein ovella vaikka kutsussa puhuttiin moniosaisesta rekryprosessista. Kaikenlaista säätöä noihin it-alan rekryihin mahtuu.

Huomasin että joulukuussa käymieni haastattelujen jälkeen pänni jo jonkin verran nuo alan rekrykuviot. Nyt Vincitin haastattelun jälkeen vitutti aidosti. Reaktorilla on tietty taso ja sinne kaivataan tietynlaisia ihmisiä, oma mahdollisuus päästä läpi on olemassa mutta todennäköisemmin en kuulu joukkoon, ja nuo kokemukset ei ole nyt tähän väliin kaivattuja.

Nyt sit voit vain jossitella, että miten olis voinut käydä. Kai nyt edes ilmoitit, että et ole tulossa?

edit: ja konsuttifirmaan ku haet, niin se on työnantajallekkin tärkeää muutenkin millainen olet haastattelutilanteessa, sut kuite tullaan asiakkaalle viemään myös ja siinä vaiheessa tollainen ajatusmaailma ei toimi. Olet osa tarjouksen voittamista.

 

[Heimolainen]

Nyt sit voit vain jossitella, että miten olis voinut käydä. Kai nyt edes ilmoitit, että et ole tulossa?

edit: ja konsuttifirmaan ku haet, niin se on työnantajallekkin tärkeää muutenkin millainen olet haastattelutilanteessa, sut kuite tullaan asiakkaalle viemään myös ja siinä vaiheessa tollainen ajatusmaailma ei toimi. Olet osa tarjouksen voittamista.

Joo jos haastattelut on erittäin vastenmielisiä tilanteita, niin kannattaa kiertää konsulttitalot.

ps: Tässä välissä joku rikkoi leiskan ja tuli aika raskaaksi sivu

 

[emagdnim]

En ajatellut jäädä jossittelemaan. Mutta tosiaan tuo konsultointi ei välttämättä ole itselle se juttu. Osittain on ja osittain ei, riippuu myös millaisia asiakkaita firmalla on.

Ihan kaikenlaisia kaikilla. Monesti tiimi koostuu useista firmoistakin.

 

[FireFly Renaissance]

Jos asiakkaat eivät ole ulkona ne ovat sisällä. Jotain kautta se raha kuitenkin aina lopulta tulee mistä ne palkat maksetaan. Vaikka koodaisi yksin mobiilipelejä jonkun pitää siitä maksaa, jos aikoo työkseen tehdä.

Tämä tosin ei ole mitenkään IT-alan erikoisuuss vaan koskee kaikkia kavinkoneenkuljettajasta jopa pääministeriin. Ei sellaista työtä olekaan missä joskus ei tarvisi tehdä asioita mitkä ei kiinnosta pätkääkään. Vittuuntuminen on luvallista, mutta ne vaan pitää tarpoa läpi, jotta pääsee taas tekemään jotain mielenkiintoisempaa. Jos mitään mielenkiintoista ei ole näkyvissäkään tai se ei riitä motivaatioksi, sitten kannattaa tehdä johtopäätöksiä johonkin suuntaan.

 

[Paapaa]

En ajatellut jäädä jossittelemaan. Mutta tosiaan tuo konsultointi ei välttämättä ole itselle se juttu. Osittain on ja osittain ei, riippuu myös millaisia asiakkaita firmalla on.

Tuohan ei selviä muuta kuin kokeilemalla. Je kokeileminen taas ei onnistu muuta kuin menemällä työhaastatteluun. Ehdottomasti kannattaa se Reaktorinkin haastis käydä tekemässä. Mitään siinä ei voi menettää (no, ehkä matkakulut jos tulet kauempaa), mutta parhaimmillaan siitä voi saada hyvän työpaikan ja hyvää palautetta, jolla parantaa tulevia mahdollisuuksiaan.

 

[vemkki]

Rivien välistä oli luettavissa, että aiempi työhaastattelu aiheutti henkisen kolauksen, eikä huvittanut heti ottaa uutta iskua vastaan toisen (oman oletuksen mukaan) todennäköisesti pettymykseen johtavan työhaastattelun muodossa. Ymmärrän sinänsä, tosin tuossa työtilanteessa ei välttämättä kannata olla valikoiva, jos kerran hakemuksesta on kiinnostuttu sen verran että on haastatteluun kutsuttu.

 

[Nigel]

Hmm... Jos Reaktori kerran on yksi halutuimmista työnantajista, niin kyllä varmaan kannattaisi ainakin sitä naamaa käydä näyttämässä ja koittaa tehdä mahdollisimman hyvä vaikutus. Vaikka sitä valintaa ei heti pääsisikään jatkoon, niin onpahan ainakin yrittänyt ja paikka saattaa sitten aueta joskus tulevaisuudessa.

 

[finWeazel]

Ensimmäiseksi työpaikaksi kannattaa hakea ja ottaa vastaan about mikä tahansa homma missä pääsee aloittamaan asap. Vaikka se nappulatestaajankin paikka on osaajalle mahdollisuus. Ihan joka hommmasta voi jotain oppia ja saada ymmärrystänsä laajennettua. Nohevat etenee alalla nopeasti.

Se voi olla kova kolaus kognitiivisen disonanssin muodossa, kun oma päänsisäinen elämä ja ulkopuolisten näkemykset eivät kohtaa. Kaikki sopivat kyllä saa töitä heti. Jos töitä ei löydy niin jotain on pielessä. Helpoin tapa korjata tilanne on olla itsellensä rehellinen vaikka se onkin henkisesti vaikeaa. Junior työpaikassa ei oleteta, että osais koodata superhyvin, tärkeintä on ne pehmeät asiat ja kyky oppia nopeasti.

 

[finWeazel]

Toi kyky oppia on monimutkainen asia. Sen sisällä on myös asioita kuten, että pitää tehdä se tehtävä mikä käsketään, 8h päivässä. Yksikään tehtävä ei ole vähäpätöinen, kun pitää viedä projekti maaliin. Ensimmäisissä koodikatselmoinneissa tule kipakkaa palautetta alkaen välilyönneistä ja päätyen koodin strukturointiin ja testaukseen. Pitää pystyä se palaute käsittelemään ja korjaamaan tuotokset. Osa porukasta ei siihen pysty ja mahdollisesti vaikeat työkaverit isolla egolla karsitaan pois haastatteluissa.

Heppu joka on egoton, ottaa palautteen vastaan ja miettii asiat läpi kehittyy nopeasti. Myöhemmin kun on näytöt annettu niin sana alkaa painamaan enemmän ja voi vaikuttaa tiimin sisällä, tiimien välillä ja ehkä myös firman laajuisesti asioihin.

 

[FireFly Renaissance]

Toi kyky oppia on monimutkainen asia. Sen sisällä on myös asioita kuten, että pitää tehdä se tehtävä mikä käsketään, 8h päivässä. Yksikään tehtävä ei ole vähäpätöinen, kun pitää viedä projekti maaliin. Ensimmäisissä koodikatselmoinneissa tule kipakkaa palautetta alkaen välilyönneistä ja päätyen koodin strukturointiin ja testaukseen. Pitää pystyä se palaute käsittelemään ja korjaamaan tuotokset. Osa porukasta ei siihen pysty ja mahdollisesti vaikeat työkaverit isolla egolla karsitaan pois haastatteluissa.

Heppu joka on egoton, ottaa palautteen vastaan ja miettii asiat läpi kehittyy nopeasti. Myöhemmin kun on näytöt annettu niin sana alkaa painamaan enemmän ja voi vaikuttaa tiimin sisällä, tiimien välillä ja ehkä myös firman laajuisesti asioihin.

No, jos aletaan välilyönneistä nipottamaan (olettaen, että koodi on luettavaa ja siistiä) niin selvästi ne isot egot ovat jo pesiytyneet peruuttamattomasti organisaatioon

 

[emagdnim]

No, jos aletaan välilyönneistä nipottamaan (olettaen, että koodi on luettavaa ja siistiä) niin selvästi ne isot egot ovat jo pesiytyneet peruuttamattomasti organisaatioon

Välilyönnit on pieni osa esim. sulkeiden kohdalla, mut jos on tyylisäännöt, niin niitä noudatetaan. Ei se nipottamista ole, palaute voi olla vaikkapa "korjaa toi vielä, muuten ok, hyväksytty"

edit: mut yleensähän lintteri fiksailee tollaset jo editorissa.

 

[FireFly Renaissance]

Välilyönnit on pieni osa esim. sulkeiden kohdalla, mut jos on tyylisäännöt, niin niitä noudatetaan. Ei se nipottamista ole, palaute voi olla vaikkapa "korjaa toi vielä, muuten ok, hyväksytty"

Sellaiset tyylisäännöt, joissa esitetään vain yksi (yleensä kirjoittajan omasta egoistisestä mielestä) täydellisen upea visuaalinen näkemys ovat aika paskoja imho. Sen tyylisäännön tarkoitus on tuottaa koodia, jossa ei ole teknisiä virheitä ei toimia alustana firman egojen kamppailulle oikeasta pilkun paikasta. Hyvässä tyylisäännössä onkin eritelty, mitkä ovat tärkeitä asioita ja mitkä eivät.

Nipottaminen on nipottamista vaikka nipotus olisikin kirjattu säännöksi

Pythonin tyylioppaassa on tästä hyvä näkemys:

A Foolish Consistency is the Hobgoblin of Little Minds

 

[emagdnim]

Sellaiset tyylisäännöt, joissa esitetään vain yksi (yleensä kirjoittajan omasta egoistisestä mielestä) täydellisen upea visuaalinen näkemys ovat aika paskoja imho. Sen tyylisäännön tarkoitus on tuottaa koodia, jossa ei ole teknisiä virheitä ei toimia alustana firman egojen kamppailulle oikeasta pilkun paikasta. Hyvässä tyylisäännössä onkin eritelty, mitkä ovat tärkeitä asioita ja mitkä eivät.

Kyllä mulla jokaisessa javascript-projektissa on oma lintteritiedosto koodityylille. Yleensä 99% "suositeltu" pohja ja jotain poikkeuksia loput, riippuen makuasioista ja frameworkista. Sit määriteltynä tietty erikseen, mitkä aiheuttaa buildin failin tai ainoastaan varoituksen jne.. kyllä niitä on hyvä seurata eikä pahastua, jos joku mainitsee poikkeavuudesta vai mihin se raja laitetaan?

Kuten jo sanoin, järkeä saa käyttää. Itse noissa pikkujutuissa vaan mainitsen asiasta, mut hyväksyn pr:n. Eikä ne ole koskaan kenenkään yksittäisiä mielipiteitä vaan tyylit, johon koko tiimi sitoutuu.

edit: ja varmasti eri ohjelmointikielissä on tärkeitä juttuja eri asiat. es6:ssaki tulee aika paljon sulkuja puhumattakaa vaikkapa clojuresta.

edit2: esim. tämäkin on nykyisessä projektissa käytössä: array-bracket-spacing - Rules

 

[FireFly Renaissance]

kyllä niitä on hyvä seurata eikä pahastua, jos joku mainitsee poikkeavuudesta vai mihin se raja laitetaan?

Millä tavalla se on hyvä? Mitä erinomaista sillä saavutetaan, jos koodi on jokatapauksessa selkeää ja helposti hahmotettavaa? Nyt en puhu tilanteesta, että joku vetää aivan omaa linjaansa mikä ei ole sinnepäinkään minkään normaalien tyylien mukaan. Jotkin muuttujien nimeämiskäytännöt tmv. voivat olla sellaisia joiden yhdenmukaistaminen on oikeasti tärkeää. Se onko sulun jälkeen väli vai ei, tai millä rivillä on { eivät ole tälläisiä asioita. Ainakin itse kykenen lukemaan kumpaakin notaatiota ihan sujuvasti.

Raja varmaan vedetään siihen, että koodi on selkeää. Onhan meillä paskempia ja parempia tyylioppaitakin. Ei niissäkään rajaa ole selvästi vedetty mihinkään tiettyyn. Vähän kuin kirjoittamisessakin. Ei täälläkään katsota hyvällä, jos jokaisesta kielioppivirheestä, tai vähemmän täydellisyyttä hipovasta lauserakenteesta, valitettaisiin. Silti oletuksena on, että kirjoitetaan ainakin jotakuinkin selkeää suomen kieltä.

 

[finWeazel]

No, jos aletaan välilyönneistä nipottamaan (olettaen, että koodi on luettavaa ja siistiä) niin selvästi ne isot egot ovat jo pesiytyneet peruuttamattomasti organisaatioon

Käytin välilyöntiä myös mielikuvana. Joku pikkuasia, mutta talossa talon säännöillä. Välilyönnithän menee kyllä kohdallensa automaatiolla nykyään(clang-tidy vaikka c/c++ koodilla).

 

[emagdnim]

Millä tavalla se on hyvä? Mitä erinomaista sillä saavutetaan, jos koodi on jokatapauksessa selkeää ja helposti hahmotettavaa? Nyt en puhu tilanteesta, että joku vetää aivan omaa linjaansa mikä ei ole sinnepäinkään minkään normaalien tyylien mukaan. Jotkin muuttujien nimeämiskäytännöt tmv. voivat olla sellaisia joiden yhdenmukaistaminen on oikeasti tärkeää. Se onko sulun jälkeen väli vai ei, tai millä rivillä on { eivät ole tälläisiä asioita. Ainakin itse kykenen lukemaan kumpaakin notaatiota ihan sujuvasti.

Raja varmaan vedetään siihen, että koodi on selkeää. Onhan meillä paskempia ja parempia tyylioppaitakin. Ei niissäkään rajaa ole selvästi vedetty mihinkään tiettyyn. Vähän kuin kirjoittamisessakin. Ei täälläkään katsota hyvällä, jos jokaisesta kielioppivirheestä, tai vähemmän täydellisyyttä hipovasta lauserakenteesta, valitettaisiin. Silti oletuksena on, että kirjoitetaan ainakin jotakuinkin selkeää suomen kieltä.

No säännöillä nimenomaan tähdätään siihen, että se on selkeää ja helposti hahmotettavaa eikä kukaan sooloile mielestään hyvällä koodilla?? Jätetään säännöt huomiotta, jätetään taas, jätetään tuoki, tuo.. jne ja puolen vuoden päästä noita onkin kasaantunut ympäri koodia?

 

[JCSH]

Millä tavalla se on hyvä? Mitä erinomaista sillä saavutetaan, jos koodi on jokatapauksessa selkeää ja helposti hahmotettavaa? Nyt en puhu tilanteesta, että joku vetää aivan omaa linjaansa mikä ei ole sinnepäinkään minkään normaalien tyylien mukaan. Jotkin muuttujien nimeämiskäytännöt tmv. voivat olla sellaisia joiden yhdenmukaistaminen on oikeasti tärkeää. Se onko sulun jälkeen väli vai ei, tai millä rivillä on { eivät ole tälläisiä asioita. Ainakin itse kykenen lukemaan kumpaakin notaatiota ihan sujuvasti.

Raja varmaan vedetään siihen, että koodi on selkeää. Onhan meillä paskempia ja parempia tyylioppaitakin. Ei niissäkään rajaa ole selvästi vedetty mihinkään tiettyyn. Vähän kuin kirjoittamisessakin. Ei täälläkään katsota hyvällä, jos jokaisesta kielioppivirheestä, tai vähemmän täydellisyyttä hipovasta lauserakenteesta, valitettaisiin. Silti oletuksena on, että kirjoitetaan ainakin jotakuinkin selkeää suomen kieltä.

Tosin tämän koko nipotusasian pitäisi nykyaikaisilla työkaluilla olla täysin turha. On se määritelty code-style, sitten painat sitä yhtä nappia jolla ajat sen formatoinnin koodille ennen kuin puskee sisään.

*edit*
Ja jos ei ole mitään olemassa olevaa code styleä projektille niin sitten otetaan joku tunnettu code style pohjaksi ja järkätään se 60 minuutin battle royal jossa väki saa 60 minuutin ajan tapella niistä muutoksista mitä tuohon pohjaan tehdään. Jossei tule konsensusta niin sitten äänestetään.
Kun tuo battle royal on lopussa niin lopputuloksena on parametrit joita sitten noudatetaan projektissa.

 

[FireFly Renaissance]

No säännöillä nimenomaan tähdätään siihen, että se on selkeää ja helposti hahmotettavaa eikä kukaan sooloile mielestään hyvällä koodilla?? Jätetään säännöt huomiotta, jätetään taas, jätetään tuoki, tuo.. jne ja puolen vuoden päästä noita onkin kasaantunut ympäri koodia?

Tällä ajattelumallilla luodaan varmaan kaikki täysin turha ja tarpeeton byrokratia maailmassa ja myös yrityksissä.

Jos tekijät ovat fiksuja ja ammattitaitoisia niin kyllä ne osaa koodata selkeää koodia ilman, että joku on pomottamassa asiasta ja kertomassa mikä on se oikea näkemys. Jopa vuodesta toiseen. (Ja myös ihan todistetusti.)

 

[JCSH]

Tällä ajattelumallilla luodaan varmaan kaikki täysin turha ja tarpeeton byrokratia maailmassa ja myös yrityksissä.

Jos tekijät ovat fiksuja ja ammattitaitoisia niin kyllä ne osaa koodata selkeää koodia ilman, että joku on pomottamassa asiasta ja kertomassa mikä on se oikea näkemys. Jopa vuodesta toiseen. (Ja myös ihan todistetusti.)

En nyt tiedä onko se turhaa byrokratiaa jos se tehdään kerralla kuntoon ja sitten nykyiset työkalut mahdollistavat sen että kun se on kerran päätetty niin sen ylläpitäminen on triviaalia.

Ja koodia voi kirjoittaa monella tapaa selkeästi. Mutta usein jos sekoitetaan montaa itsestään selkeää tapaa niin lopputulos ei ole enää selkeää. Jonka takia on hyvä että on se yksi valittu selkeä tapa jota kaikki seuraa.

 

[finWeazel]

Mun pointti ei ollut välilyönnit vaan se, että jos on yhteisiä sääntöjä niin niitä pitää pystyä noudattamaan. Samoin, jos tulee kriittistä palautetta se pitää pystyä käsittelemään asiallisesti. Kaikki eivät tuohon pysty. Junior rekry ei ole se kaveri, joka säätää firman säännöt uusiksi. Jos se junior antaa näytöt ja kasvaa senioriksi niin siinä matkan aikana vaikutusvalta kasvaa. Junioria ei palkata pelkän koodaustaidon takia, se on juniori. Se palkataan niiden kykyjen ansiosta, jotka saavat työnantajan uskomaan, että tohon kaveriin satsataan ja siitä kasvaa seniori.

Pragmatic Programmer kirjaa suosittelen myös super senioreille,jos sitä ei ole vielä lukenut. Siinä puhutaan mm. rikkinäiset ikkunat mallista. Jos homma lähtee ränsistymään niin kohta mitkään säännöt ei päde ja kaikki menee paskaksi. Pikkutaloissa ei lähde niin nopeaan lapasesta kuin isoissa myllyissä.

Yksi tapa mieltää kooderi urakehitystä voi olla

tarvii apua, ei pärjää yksin
Pärjää yksin noudattaen ohjeita
Pärjää yksin, ei tarvi ohjeita
Pärjää yksin, auttaa omia tiimiläisiä
Pärjää yksin, auttaa omaa ja muita tiimejä
Pärjää yksin, vaikuttaa koko yritykseen

Se on aika rajallista mihin asti uralla pääsee, jos ei osaa eikä halua osata pehmeitä asioita. Iso osa seniorin työstä voi olla ihmisten kanssa työstämistä ja oman työpanoksen monistamista muiden kautta. Asiathan on ihan erilaisia 10 hepun firmassa versus tuhansia ihmisiä työllistävässä globaalissa firmassa. Jokaiselle löytynee se oma lokero, kunhan tunnistaa omat vahvuudet/heikkoudet ja sen mitä haluaa tehdä.

 

[FireFly Renaissance]

En nyt tiedä onko se turhaa byrokratiaa jos se tehdään kerralla kuntoon ja sitten nykyiset työkalut mahdollistavat sen että kun se on kerran päätetty niin sen ylläpitäminen on triviaalia.

Ja koodia voi kirjoittaa monella tapaa selkeästi. Mutta usein jos sekoitetaan montaa itsestään selkeää tapaa niin lopputulos ei ole enää selkeää. Jonka takia on hyvä että on se yksi valittu selkeä tapa jota kaikki seuraa.

Riippuu toki siitä kuinka monta kokkia hämmentää samaa soppaa. Yleensä on parasta, että saman kattilan kimpussa on mahdollisimman vähän häärääjiä.

Mutta juu, jos virittelee työkäkalut, työkalut löytyvät käytetyille kielille ja integroituvat muuhun ympäristöön ja joku katsoo sellaisen hyödyt olevan suuremmat kuin tuhrattu aika niin toki niitä koodeja voi siinä tilanteessa ajella jonkun automaattikaunistelijan läpi. Siinä oli kuitenkin monta jossia

Pragmatic Programmer kirjaa suosittelen myös super senioreille,jos sitä ei ole vielä lukenut. Siinä puhutaan mm. rikkinäiset ikkunat mallista. Jos homma lähtee ränsistymään niin kohta mitkään säännöt ei päde ja kaikki menee paskaksi. Pikkutaloissa ei lähde niin nopeaan lapasesta kuin isoissa myllyissä.

Isossa myllyssä koodia tulee joka tapauksessa joka suunnasta ja jokaisen kumppanin/alihankkijan/asiakkaan/generaattorin jne. näkemysten mukaisesti, useilla kielillä, ja niitä joudutaan muokkaamaan / integroimaan siihen omaan tekemiseen tai siihen joskus tehtyyn legacyyn. Se, että kaikki projektissa käpisteltävä koodi olisi jonkun yhden tyyliohjeen mukaista voi joka tapauksessa unohtaa saman tien.

 

[Antti Alien]

Sellaiset tyylisäännöt, joissa esitetään vain yksi (yleensä kirjoittajan omasta egoistisestä mielestä) täydellisen upea visuaalinen näkemys ovat aika paskoja imho. Sen tyylisäännön tarkoitus on tuottaa koodia, jossa ei ole teknisiä virheitä ei toimia alustana firman egojen kamppailulle oikeasta pilkun paikasta. Hyvässä tyylisäännössä onkin eritelty, mitkä ovat tärkeitä asioita ja mitkä eivät.

Nipottaminen on nipottamista vaikka nipotus olisikin kirjattu säännöksi

Pythonin tyylioppaassa on tästä hyvä näkemys:

Tyylisääntöjen tarkoitus ei ole tuottaa virheetöntä koodia. Toki osa säännöistä auttaa siinä (esimerkiksi lohkojen käyttäminen aina, vaikka lohko koostuisi yhdestä lausekkeesta), mutta suurimmaksi osaksi tyylisäännöt ovat helpottamassa luettavuutta. Kun kaikki kirjoittavat samannäköistä koodia, sitä on äärettömästi helpompi silmäillä, kuin jos jokainen keksii omat sääntönsä esimerkiksi tyhjän tilan käytölle.

Tiivistelmä tuosta Pythonin tyylioppaan palasta: konsistentti tyyli on erittäin tärkeää, mutta joskus tyylisäännöt johtavat hankalammin luettavaan koodiin, joten järkeäkin saa käyttää.

 

[JCSH]

Riippuu toki siitä kuinka monta kokkia hämmentää samaa soppaa. Yleensä on parasta, että saman kattilan kimpussa on mahdollisimman vähän häärääjiä.

Mutta juu, jos virittelee työkäkalut, työkalut löytyvät käytetyille kielille ja integroituvat muuhun ympäristöön ja joku katsoo sellaisen hyödyt olevan suuremmat kuin tuhrattu aika niin toki niitä koodeja voi siinä tilanteessa ajella jonkun automaattikaunistelijan läpi. Siinä oli kuitenkin monta jossia

No jos sulla on joku semmonen suht normi about 10 koodarinkin tiimi työstämässä yhtä softaa niin kyllä siinä aika nopeasti törmätään siihen tilanteeseen että ne yhteiset käytännöt on hyvät.

Ja ei tuohon nyt oikeasti mene aikaa. Okei, jos väännetään jotain Cobolia työkaluilla vuodelta 1975 niin sitten voi mennä aikaa tuohon setuppiin.
Mutta jos kyseessä on modernit kielet ja työkalut niin se on maksimissaan se about tunti per kieli (jos nyt oikeasti haluaa pitää tuon battle royalen sen sijaan että joku vaan koodinatsin natsoilla valkkaa sen yhden olemassaolevan stylen) ja sitten about 5 minuuttia että jokainen devaaja konffaa sen käyttämänsä IDE:n / editorin.

 

[JCSH]

Isossa myllyssä koodia tulee joka tapauksessa joka suunnasta ja jokaisen kumppanin/alihankkijan/asiakkaan/generaattorin jne. näkemysten mukaisesti, useilla kielillä, ja niitä joudutaan muokkaamaan / integroimaan siihen omaan tekemiseen tai siihen joskus tehtyyn legacyyn. Se, että kaikki projektissa käpisteltävä koodi olisi jonkun yhden tyyliohjeen mukaista voi joka tapauksessa unohtaa saman tien.

Ja lopputuloksena on VR:n lipunmyynti softa

*edit*

Vähän vakavammin, sähän tuossa sorrut juurikin tuohon broken windows ongelmaan josta finWeazel puhui. Hyväksyt että homma menee vituiksi niin miksi edes yrittää.

 

[buumi]

Ja ylipäätään mikä ongelma siinä on, että huomautetaan pienestä tyylivirheestä? Luulisi sen olevan selvää, että yhtenäisesti muotoiltu koodi on helpompaa ylläpitää ja sen korjauksen tekemiseen menee n. minuutti. Jos joku siitä loukkaantuu, että omaa täydellistä koodia kommentoidaan jonkun "pikkumaisuuden" takia niin mielestäni ihan oma häpeänsä.

Edit: Paljon isompi ongelma on se, jos joutuu varomaan katselmointi-tilanteessa, että minkälaisia kommentteja saa antaa ilman että toinen loukkaantuu.

 

[Incredible Buff]

Tuossa taannoin oli keskustelua, että miksi työpaikat ei laita te-keskuksen sivuille avoimia paikkoja.

Kaveri, joka on kyllä insinööri ja on koodannut nettisivuja viimeksi 2006 tai jotain, on ollut tovin työttömänä. CV:stä löytyy Nokiaa ja isoja konsulttitaloja, mutta mutta UX:n tai graafisen designerin roolissa. No työkkäri oli paukauttanut kaverille pakkohaun C-koodariksi. Kaveri ei osaa eikä halua koodata. Firma joutuu turhan päiten käyttämään resursseja sitten hakemusten läpi käymiseen eikä varmasti ole ainoa ei-relevantti hakemus työkkärin takia.

Vieläkö pitää ihmetellä miksei monikaan firma julkaise te-keskuksen kautta paikkoja?

 

[Wemps]

@jaaha n seikkailuita lukiessa tuli mieleen, että paljonkohan Vincitillä ja Reaktorilla maksetaan junnuille, jos on noinkin monimutkaiset esitehtävät ja haastattelukuviot?

Sen tiedän että monissa pienemmissä softataloissa devaamaan pääsee junior-tasolle huomattavasti helpommilla esitehtävillä, eikä todellakaan tarvitse olla osaaja etukäteen, jos nyt on jonkinlaista kokemusta koodista ennestään. Silloin palkka on aika lailla mallia tekin suositukset.

Saako vincitiltä tai reaktorilta ym enemmän, vai hakeeko porukka sinne vain että saa vincitin tai reaktorin omaan cvseen?

 

[emagdnim]

@jaaha n seikkailuita lukiessa tuli mieleen, että paljonkohan Vincitillä ja Reaktorilla maksetaan junnuille, jos on noinkin monimutkaiset esitehtävät ja haastattelukuviot?

Sen tiedän että monissa pienemmissä softataloissa devaamaan pääsee junior-tasolle huomattavasti helpommilla esitehtävillä, eikä todellakaan tarvitse olla osaaja etukäteen, jos nyt on jonkinlaista kokemusta koodista ennestään. Silloin palkka on aika lailla mallia tekin suositukset.

Saako vincitiltä tai reaktorilta ym enemmän, vai hakeeko porukka sinne vain että saa vincitin tai reaktorin omaan cvseen?

Vincitillä näkyy suoraan kamppiksessa ainaki kesäduunarin palkka. 2500e/kk TRE ja 2600e/kk HKI.

 

[Makos]

Käytin välilyöntiä myös mielikuvana. Joku pikkuasia, mutta talossa talon säännöillä. Välilyönnithän menee kyllä kohdallensa automaatiolla nykyään(clang-tidy vaikka c/c++ koodilla).

Itsehän olen sen tason guru nykyduunissa, että oma koodini menee clang-tidyn ohi poikkeussäännöllä sellaisenaan

 

[Wemps]

Vincitillä näkyy suoraan kamppiksessa ainaki kesäduunarin palkka. 2500e/kk TRE ja 2600e/kk HKI.

No ei tuo nyt miltään tähtitieteelliseltä kyllä kuulosta. Useampi kaveri sai osa-aika / kesäduunia parhaimmillaan (tai pahimmillaan) keskeneräiseltä yliopiston ohjelmoinnin sivuaine -pohjalta esim c++/web/sql -hommiim muutamassa tamperelaisessa firmassa, ja kaikilla palkka vähintään luokkaa 2200-2300e + edut kuten lounarit.

Toki en kiellä, ettenkö itsekin mielummin menisi Reaktorille kuin johonkin tuntemattompaan firmaan ihan urakehityksen puolesta, mutta toisaalta vaatimukset ja oletettavasti suorituspaineet Reaktorilla ihan eri luokkaa, ja lisäpalkkaa vain se satanen tai pari.

 

[Jorsetti]

Toisaalta pienissä firmoissa ei ole varaa mihinkään läskeilyyn, eli alle 10 hengen firmoissa varmasti pääsee työntämään kädet syvälle saveen niin halutessaan.

 

[oongee]

Tuohan ei selviä muuta kuin kokeilemalla. Je kokeileminen taas ei onnistu muuta kuin menemällä työhaastatteluun. Ehdottomasti kannattaa se Reaktorinkin haastis käydä tekemässä. Mitään siinä ei voi menettää (no, ehkä matkakulut jos tulet kauempaa), mutta parhaimmillaan siitä voi saada hyvän työpaikan ja hyvää palautetta, jolla parantaa tulevia mahdollisuuksiaan.

Eikä menetä edes matkakuluja, jos on ilmoittautunut työttömäksi, kunhan täyttelee TE-toimiston lappusen. Sain itse juuri 58,98 € verran verorahoille vastinetta kun kävin Helsingistä käsin Tampereella työhaastattelussa.

Seuraavasta lisätietoja: Matka- ja yöpymiskustannukset ja liikkuvuusavustus- TE-palvelut

 

[mt247]

Tällaiseen fantasia-rekrytointikieleen ei edes Tampereen yliopisto pysty: Haluatko Supoon syvän päädyn uimariksi tai pähkinänjärsijäksi? - Tolkun Henkilö

Suojelupoliisi houkuttelee nörttejä palvelukseensa jännällä nuorisolaiskielellä: etsii teknomaageja ja altaan syvässä päädyssä uivia valkohattuhakkereita.

seura.fi

Supolla olisi auki paikka teknomaagille :

”Oletko sinäkin ongelmien ratkoja, pähkinöiden pureksija, teknomaagi tasokattosi huipulla? Sinua eivät hiekkalaatikon reunat pidättele, uit altaan syvässä päässä ja liikut sulavasti myös sivuttain.”

 

[FireFly Renaissance]

Vähän vakavammin, sähän tuossa sorrut juurikin tuohon broken windows ongelmaan josta finWeazel puhui. Hyväksyt että homma menee vituiksi niin miksi edes yrittää.

Viisaus alkaa tosiasioiden tunnustamisesta Toivotan onnea sille, joka päättää vaikka kansainvälisessä multi-site projektissa kertoa miten sitä koodia meillä tehdään. Tuskin sitä ainakaan pakottamaan pystyy.

Ja ylipäätään mikä ongelma siinä on, että huomautetaan pienestä tyylivirheestä? Luulisi sen olevan selvää, että yhtenäisesti muotoiltu koodi on helpompaa ylläpitää ja sen korjauksen tekemiseen menee n. minuutti. Jos joku siitä loukkaantuu, että omaa täydellistä koodia kommentoidaan jonkun "pikkumaisuuden" takia niin mielestäni ihan oma häpeänsä.

No ei se varmaan sinänsä mikään ongelma ole, jos on se junnu ekassa työpaikassa, mutta jos on iät ajat kirjoittanut jollain toisella tyylillä, nin melko ärsyttävää se on väkisin koittaa tehdä ihan eri tavalla. Vielä ärsyttävämpää korjailla jotain koodia, siksi, että joku jaksaisi asiasta jonkun pikku muotovirheen takia valittaa. Tai ainakin kuvittelisin näin, koska moista turhamaisuutta en oikeassa elämässä ole kyllä ikinä kohdannut.

Itse pääsin yhtä koodiopasta tekemään niin noudatin kyllä ohjenuoraa, jos sen ei tarvi ollla sääntö, sen ei pidäkään olla sääntö. Ja suositukset != sääntö.

Edit: Paljon isompi ongelma on se, jos joutuu varomaan katselmointi-tilanteessa, että minkälaisia kommentteja saa antaa ilman että toinen loukkaantuu.

No nää on varmaan niitä peräänkuulutettuja softskilssejä. Ihmiset eivät noin lähtökohtaisesti yleensä pidä mikromanageroinnista.

 

[Jorsetti]

Suponkin kannattaisi miettiä, että voisiko niitä kovan luokan mustahattujakin palkata omille listoilleen. Heissä sitä osaamistakin olisi, tosin yleinen henkilöstöhallinta voi olla näissä haasteellista.

 

[JCSH]

Viisaus alkaa tosiasioiden tunnustamisesta Toivotan onnea sille, joka päättää vaikka kansainvälisessä multi-site projektissa kertoa miten sitä koodia meillä tehdään. Tuskin sitä ainakaan pakottamaan pystyy.

No toistaiseksi jokaisessa kansainvälisessä multi-site projektissa jossa on tullut oltua viimeisen 12 vuoden aikana neljässä eri yrityksessä ei ole ollut ongelmia sen kanssa että sovitaan se yksi code style jota kaikki sitten noudattaa...

 

[emagdnim]

No nää on varmaan niitä peräänkuulutettuja softskilssejä. Ihmiset eivät noin lähtökohtaisesti yleensä pidä mikromanageroinnista.

Tiimin yhteisten sääntöjen noudattaminen ei ole mikromanagerointia. Jos tiimissä moista esiintyy, nii se on isompi ongelma. Sulkeet/tyhjä tila oli esimerkki, painotukset voi olla eri kielillä ihan toisenlaisia, mut pienistä jutuista tyylisäännöt koostuu. Toki voi aina olemassa tiimejä, joissa hyvinkin väljillä säännöillä mennään.
Mut mitä on sovittu, siinä pysytään. Oli sitten välilyönti sinne ja välilyönti pois täältä. Tiimitkin toki elää ja säännötkin voi elää, mut ne on aina tiimin yhteisiä juttuja. Siinä missä junnu harvemmin näistä päättää, niin yhtä vähän tiimin uusin henkilö. Hänellä voi olla sanottavaa ja hyvin ku perustelee, niin saattaa muutosta saada aikaiseksi. Silloinkin kaikki noudattaa mahdollisesti uusia sääntöjä. Mikä tossa on vastenmielistä ja vaikeaa?

 

[FireFly Renaissance]

Tiimin yhteisten sääntöjen noudattaminen ei ole mikromanagerointia. Jos tiimissä moista esiintyy, nii se on isompi ongelma. Sulkeet/tyhjä tila oli esimerkki, painotukset voi olla eri kielillä ihan toisenlaisia, mut pienistä jutuista tyylisäännöt koostuu. Toki voi aina olemassa tiimejä, joissa hyvinkin väljillä säännöillä mennään.
Mut mitä on sovittu, siinä pysytään. Oli sitten välilyönti sinne ja välilyönti pois täältä. Tiimitkin toki elää ja säännötkin voi elää, mut ne on aina tiimin yhteisiä juttuja. Siinä missä junnu harvemmin näistä päättää, niin yhtä vähän tiimin uusin henkilö. Hänellä voi olla sanottavaa ja hyvin ku perustelee, niin saattaa muutosta saada aikaiseksi. Silloinkin kaikki noudattaa mahdollisesti uusia sääntöjä. Mikä tossa on vastenmielistä ja vaikeaa?

En nyt ymmärtänyt, että miten niin mikromanagerointi ei ole mikromanagerointia?

Tiedän, että on olemassa ihmisiä, jotka eivät muuta teekään kuin rakasta kaikenlaisia sääntöjä (ja prosesseja). Valitettavasti läheskään kaikki ihmiset eivät kuitenkaan kuulu tähän ryhmään. Näitä, usein luovempia ihmisiä, kaikki pikkutarkat säännöt vain ottavat päähän. Jos tiimi ei siis koostu pelkistä pilkunrakastajista, niin silloin ei kannata myöskään sääntöjäkään virittää vain näiden ihmisten ehdoilla.

Ja vaikka se junnu (tai "uusi henkilö") ei päättäisi mistään, niin se saattaa silti nostaa kytkintä heti kun ensimmäinen tilaisuus tulee.

 

[finWeazel]

Haastattelutilanne on 2 suuntainen tie. Puolin ja toisin mietitään yhteensopivuutta. Jos on FCK the rules mentaliteetilla liikenteessä niin ehkä ei kannata hakea asiakasrajapintaan konsulttifirmassa tai spacex:aan rakentamaan raketteja. Toisessa tapauksessa asiakas säätää miten tehdään(ja asiakkaat vaihtuu) ja toisessa tapauksessa on paljon standardeja ja prosesseja joita pitää noudattaa. Samoin sen haastateltavan kannattaa kysellä firman kulttuurista ja toimintatavoista, että selviää tehdäänkö töitä sellaisella tavalla, joka sopii omalle kohdalle.

Joku pikkufirma, missä ei tarvi integroida isoja kokonaisuuksia pakettiin sopii niille, jotka haluaa sooloilla. Ei tule sooloilu ongelmaksi, kun projektien koko on riittävän pieni. Tai sitten tosiaan tulee niitä vr:n junalippuprojektejakin, jotka ei mene maaliin

Mä monesti kysyn jostain asiasta että miten voisi tehdä paremmin, jotta näen miten haastateltava reagoi ja kuinka syvälle osaaminen menee. Jos haastateltava tulee kuin kissa silmille, että että kerro itse miten tekisit paremmin niin hylsyhän siitä tulee. Esitehtävästä kysyminen on otollinen tapa kokeilla kepillä jäätä, että miten haastateltava käyttäytyisi koodikatselmointitilanteessa/ottaa kriittistä palautetta vastaan.

 

[JCSH]

En nyt ymmärtänyt, että miten niin mikromanagerointi ei ole mikromanagerointia?

Tiedän, että on olemassa ihmisiä, jotka eivät muuta teekään kuin rakasta kaikenlaisia sääntöjä (ja prosesseja). Valitettavasti läheskään kaikki ihmiset eivät kuitenkaan kuulu tähän ryhmään. Näitä, usein luovempia ihmisiä, kaikki pikkutarkat säännöt vain ottavat päähän. Jos tiimi ei siis koostu pelkistä pilkunrakastajista, niin silloin ei kannata myöskään sääntöjäkään virittää vain näiden ihmisten ehdoilla.

Ja vaikka se junnu (tai "uusi henkilö") ei päättäisi mistään, niin se saattaa silti nostaa kytkintä heti kun ensimmäinen tilaisuus tulee.

Ei se ole mitään jazz improvisointia, se on sorsakoodia. Jos todellakin se formaatterin ajaminen, joka vaatii yleensä sen yhden näppäinyhdistelmän painamisen, tukahduttaa jonkun koodarin luovuuden niin en kyllä nyt oikein tajua mitä sanoa.
Sanoisin jopa että en muista koskaan törmänneeni koodariin jolle tuo aiheuttaisi ongelmia. Mitä ikinä mieltä he ovatkaan kyseisestä style guidesta niin silti tietävät miksi style guidet ovat olemassa ja sitten ammattilaisina noudattavat niitä.
Toki tuo ei tarkoita että valitettaisiin jokaisesta white spacesta joka poikkeaa guidesta mutta että pääasiassa sitä guidea seurataan.

 

[Randomizer]

Nuo tyyliasiat saa yleensä kerralla kuntoon että ajaa verifioinneissa muutokset jonkin tyyli/convention checkerin läpi. Tämän koko prosessin voi tietysti automatisoida, eikä yhtään väärällä tyylillä tehtyä committia pääse mestarihaaraan.

 

[Bladekill]

Sanoisin jopa että en muista koskaan törmänneeni koodariin jolle tuo aiheuttaisi ongelmia. Mitä ikinä mieltä he ovatkaan kyseisestä style guidesta niin silti tietävät miksi style guidet ovat olemassa ja sitten ammattilaisina noudattavat niitä. Toki tuo ei tarkoita että valitettaisiin jokaisesta white spacesta joka poikkeaa guidesta mutta että pääasiassa sitä guidea seurataan.

Aamen. Omalla kohdallani kaikista parhaimmat, tehokkaimmat, vähä-ongelmaisimmat ja laadukkaimmat projektit ovat olleet ne jossa on heti alussa uusille devaajille lyöty selkeät pelisäännöt ja toimintatavat joilla mennään. Ei nillitystä mutta aivan normaalit devauksen käytännöt kuten commit message -formaatti, koodityylit, arkkitehtuuri, käytännöt, kommunikointikanavat/tavat jne. Projekteissa taas missä kaikki tehdään vähän miten sattuu ja jengi menee "omalla tyylillään", paska haisee kilometrien päähän ja jatkuvasti tulee kömmähdyksiä/väärinkäsityksiä.

Ensimmäiset pari viikkoa voi tuntua kankealta, mutta pian käytännöt tulevat ajattelematta ja sitten homma menee nappiin lähes automaattisesti. Kyse ei todellakaan ole mistään mikromanageroinnista kun kyse ei ole edes manageroinnista vaan yhteisesti sovittavista pelisäännöistä joihin koko tiimi sitoutuu.

@jaaha n seikkailuita lukiessa tuli mieleen, että paljonkohan Vincitillä ja Reaktorilla maksetaan junnuille, jos on noinkin monimutkaiset esitehtävät ja haastattelukuviot?

Sen tiedän että monissa pienemmissä softataloissa devaamaan pääsee junior-tasolle huomattavasti helpommilla esitehtävillä, eikä todellakaan tarvitse olla osaaja etukäteen, jos nyt on jonkinlaista kokemusta koodista ennestään. Silloin palkka on aika lailla mallia tekin suositukset.

Saako vincitiltä tai reaktorilta ym enemmän, vai hakeeko porukka sinne vain että saa vincitin tai reaktorin omaan cvseen?

Reaktorilla junnuliksat devaajille taitaa olla (tai ainakin muutama vuosi sitten olivat) jossain 2500-3000 välissä. 2500 suuntaan kallistuu jos on koulusta tullut kesäri "sormi suussa" ja jos taas työelämässä oleva junnu niin sitten varmaan lähemmäs 3k. Päälle lounassetelit ja muut edut.

Vincitistä en tiedä, mutta ainakin Futuricella Helsingissä oli paljon huonommat palkat ja he käyttävät/käyttivät maagista "taulukkoaan" jolla yritettiin lukita ihmisiä tietylle tasolle tai heidän oli pakko siirtyä manageriksi, "change agent agile innovator hype"-bullshit paskanjauhajaksi yms. Joskus oli huvittavia tilanteita kun Futuricella 3200e tienanneelle tyypille tarjottiin muualta 4800e ja vastatarjous oli 3400e tms, koska "taulukko". Jokainen varmaan arvaa miten kävi...liekkö sitten oppineet noilta ajoilta.

 

[FireFly Renaissance]

Sanoisin jopa että en muista koskaan törmänneeni koodariin jolle tuo aiheuttaisi ongelmia. Mitä ikinä mieltä he ovatkaan kyseisestä style guidesta niin silti tietävät miksi style guidet ovat olemassa ja sitten ammattilaisina noudattavat niitä.

Mäkin tiedän miksi style guidet ovat olemassa, mutta en silti tiedä miksi useimmat style guidet ovat olemassa. Hyviäkin on toki nähty. Ja moderneilla kielillä on tietenkin ihan virallisia tyyliohjeita (minkä mukaan toivottavasti mennään).

Toki tuo ei tarkoita että valitettaisiin jokaisesta white spacesta joka poikkeaa guidesta mutta että pääasiassa sitä guidea seurataan.

Siitäkin on varmaan näkemyksiä mitä "pääasiassa" tarkoittaa. Nythän on puhuttu nillittämisestä.

 

[Juha Kokkonen]

Palataanpas sitten niistä koodin tyylisäännöistä takaisin ketjun aiheeseen...

 

[Illotus]

Tällainen systeemi on ainakin Wapicella. Ilmoittelevat "avoimia työpaikkoja", mutta työhaastattelussa kerrottiinkin, että ottavat sitten yhteyttä jos tulee sopiva projekti. Ei antanut kovin hyvää kuvaa firmasta. Menin silti töihin kun sattuivat sopivassa välissä kutsumaan.

Osalla tätä systeemiä käyttävistä firmoista myös palkkausmalli vaikuttaa. Jos esimerkiksi on joku 3000 peruspalkka ja sitten laskutuksesta loput, niin voi myös olla aika nihkeä saada osaajia rekryttyä, jos ei ole projektia mihin pistää suoraan.

 

[Mendel]

Kysästääns ny sitte. Mä oon tehny yhden uran ekalla työnantajalla muussa kuin koodaustehtävissä, jossa kuitenki ratkottiin loogisia ongelmia ja sen jälkeen jatkanu joskus muinoin keskenjääneitä tieto ja viestintätekniikan opintoja. Opinnot menneet hyvin. (nelosia ja vitosia )Sain harjoittelupaikan ja lopputyöpaikan koodausalan firmasta muutamaksi kuukaudeksi. Harjoittelun loppuvaiheessa tarkoitus valmistua insinööriksi ja tunnustella työpaikkaa. Molemmat osapuolet alustavasti asiaa sivuavissa kahvikeskusteluissa varovaisen toiveikkaita jatkon suhteen jos kaikki jatkuu nykytahtia. Oletan että minun kuuluu varsinaisessa työhakemuksessa esittää palkkatoive. Mikä voisi olla reilu summa noin niinku suunnilleen? (pääkaupunkiseudun ulkopuolella)

 

[SundeR]

Kysästääns ny sitte. Mä oon tehny yhden uran ekalla työnantajalla muussa kuin koodaustehtävissä, jossa kuitenki ratkottiin loogisia ongelmia ja sen jälkeen jatkanu joskus muinoin keskenjääneitä tieto ja viestintätekniikan opintoja. Opinnot menneet hyvin. (nelosia ja vitosia )Sain harjoittelupaikan ja lopputyöpaikan koodausalan firmasta muutamaksi kuukaudeksi. Harjoittelun loppuvaiheessa tarkoitus valmistua insinööriksi ja tunnustella työpaikkaa. Molemmat osapuolet alustavasti asiaa sivuavissa kahvikeskusteluissa varovaisen toiveikkaita jatkon suhteen jos kaikki jatkuu nykytahtia. Oletan että minun kuuluu varsinaisessa työhakemuksessa esittää palkkatoive. Mikä voisi olla reilu summa noin niinku suunnilleen? (pääkaupunkiseudun ulkopuolella)

Vaikea kysymys, itse aloitin aikanaan ekassa työpaikassa jollain kämäisellä 2200€ kk-palkalla. Aluksi tärkeintä on saada kokemusta ja oppia hommiin. Vuoden parin päästä on sitten ihan eri tilanne palkkapyynnön suhteen eli lisää liksaa tai vaihtaa firmaa. Mun mielestä alussa on vain tärkeintä kerätä kokemusta. Eli en huolehtisi niin paljon palkasta, mutta tietty sieltä ylärajoilta kannattaa pyytää, varmasti enemmän kuin tuo 2200 nykypäivänä

 

[demas]

@SundeR kanssa täysin samoilla linjoilla, että tärkeintä on päästä duuniin (samaa muistaakseni sanoin eräälle ketjun ahkerimmista kirjoittajista joskus). Itse en olisi huolissaan palkasta enkä niinkään työtehtävistäkään..kun pääset töihin niin voit rauhassa katsella muualle mielenkiintoisempiin paikkoihin ja isompiin palkkoihin. Ja tietysti kannattaa heti pyrkiä "unelmaduuniin" mutta ymmärtänet @Mendel pointin

Palkasta niin yleensä palkkatoive on sellainen että kunhan sillä ei pelaa itseä ulos niin se on hyvä ja siitä voidaan sitten keskustella. Varmaan palstalla on sellaisia jotka ovat IT-alan inssihommissa viime vuosina aloittaneet.

 

[Jumi]

Nyt on 2kk kurssia takana ja voi pirkana kun elämä hymyilee. Ensinnäkin pääsin pois työttömyyden kierteestä, ja vuorokausirytmi & mielekäs tekeminen on jotain jonka olin jo unohtanut työttömyyden ja 3-vuoro tehdastöiden aikana.

Muistan kun kirjoitin hakemukseeni että "pidän uuden oppimisesta", en muistanut sitä ihan tälläiseksi! Opettelin aikoinaan 90-luvulla musiikin teon träkkereillä omaan tahtiin vaihtelevalla menestyksellä ja sama koskee kaikkea muutakin (Unity & C# perusjutut)... Jumalauta tällä kurssilla tehdään ja "ylitsepääsemättömiä seiniä" on noussut eteen joka viikko! Rekursiot esiteltiin heti toisella tai kolmannella viikolla ja tahti on ollut erittäin kova ja hyvä. Esim. tänä aamuna saatiin kaksi tuntia aikaa tehdä tic-tac-toe (9-ruudun ristinolla) ja sen jälkeen arvosteltiin toistemme koodeja. Suurimman osan opetetusta tajuaa hyvin, osan jollain tasolla, ja osa menee yli hilseen niin että sen tajuaa vasta seuraavalla viikolla tai joskus. Olisipa tahti ollut sama myös tekussa aikoinaan, näin jälkeenpäin huomaan kuinka en yrittänyt tehdä siellä yhtään enempää kuin oli pakko, ja se kyllä kostautui. Ei minun vanhalta luokalta taida olla ohjelmistoalalla kuin se yksi tyyppi.

Tälle kurssille hakijoita oli reilu 70 ja sisään pääsi lopulta 13, joka tarkoittaa että kaikki ovat erittäin motivoituneita harrastajia, jotka syystä tai toisesta ovat jättäneet koulut kesken jne. Taso vähän vaihtelee, mutta erittäin hyvää aikuista porukkaa.

Harjoittelu alkaa kuun lopussa paikallisessa reilun 10 hengen firmassa. Viime kesänä tullut työkkärin viesti joka ajoi minut tähän jamaan taisi olla yksi elämäni käännekohdista.

Osa 3: Harjoittelija ammattilaisten seassa

Tapahtui viime jaksossa: Työkkärin (Sipilän hallituksen? ) rahoittaman paikallisen firman toteuttama kokonaisuudessaan 7kk pituisen C++-kurssin teoriaosuus 3kk oli ohi ja pääsin siirtymään oikeaan IT-alan firmaan harjoittelijaksi.

Heti ensimmäiseksi sanottava etteivät kaikki 13 kurssilla olijaa saaneet harjoittelupaikkaa, lopulta tilanne taisi olla että 8 sai paikan.

Työpaikkahaastattelu firmaani oli ikimuistoinen. Painoin ovikelloa klo. 13:55 ja hetken kuluttua pomo tuli avaamaan oven jonka jälkeen siirryttiin kokoushuoneeseen jonka pöydällä retkottivat amiksesta tutut oskilloskooppi ja spektrianalysaattori.
-"Nuita en olekaan käyttänyt vähään aikaan."
-"Mutta tuttuja on?"
-"Joo toki, mutta amiksessa viimeksi käyttäny... Säätää asteikon ja son siinä."
-"Jos näiden käyttöluonnistuu ja elektroniikka kiinnostaa niin niitäkin hommia riittää. Teemme täällä monipuolisia juttuja."

Sitten istuttiin alas ja 2 sekunnin hiljaisuuden jälkeen aloin kertoa itsestäni kovasti jännittäen; C64 ala-asteen ekalla joululahjaksi, pari vuotta myöhemmin sillä tehty D10 noppa Kyberpunk 2020 -roolipeliin (vain yksi rivi koodia), eka 486 yläasteella (träkkerimusiikki ja config.sys & autoexec.bat että saa pelit päälle), amiksen elektroniikka-asentajantutkinto, keskeytynyt korkeakoulututkinto (en ole 100varma mainitsinko että keskeytyksiä oli itseasiassa 3, ja ne kaduttavat sanoin kuvaamattomasti!) ja siirtyminen hanttihommiin/pätkätöihin/työttömyyteen/vuorotöihin, omat pienet ohjelmointiprojektit (edellisissä viesteissä mainittu sudokun ratkoja). Välissä ääneni alkoi väristä aika paljonkin enkä saanut pidettyä sitä oikein mitenkään hallinnassa. Sitten pomo otti ohjat käsiinsä ja alkoi kertoa mitä täällä oikein tehdään. "Jos haluat kehittyä niin täällä se on mahdollista. Omatoimista. Olemme pieni firma ja porukka on kokenutta... Yli 20v hyvinki on suurimmalla osalla kokemusta... ja avuliasta kans, mutta apua tulee hakea itse, ja ottaa se vastaan. Kaikki on hyvin paljon itsestä kiinni."

Sitten 10 minuutin jälkeen kuulin ne sanat! "Joo, ihan hyvältä kuulostaa kyllä minä sinut ottasin. Nämä haastattelut on aina vain puhetta. Jokainen voi puhua mitä haluaa, mutta se tekeminen on eri homma ja se selviää vain tekemällä."
"... Kaupat tuli!"

Klo. 14.07 olin jo rakennuksen pihalla, haastattelu oli kestänyt n. 10 minuuttia. Suurimman vaikutuksen minuun teki ettei paskapuhetta ollut yhtään - 0. Sellaista: "meidän firma on innovaation keskus.." pirulainen kun inhoan sellaista. Sellaisesta oikein paistaa läpi ettei ole mitään sanottavaa, ja sitähän Oulun start-up maailmassa kuuli tällä vuosikymmenellä aivan vitusti, tai ainakin minä kuulin illan istujaisissa. Siksi sitä haluan korostaa ja nostaa esille tuon Tampereen Yliopiston jutun josta voisi kirjoittaa viestin jos toisenkin toiseen ketjuun.

Takaisin nykypäivään. Nyt on reilut 2kk harjoittelua takana pienessä (ja persoonallisessa) IT-alan firmassa. Ensimmäisenä päivänä sain läppärin ja työkaverin jonka projektiin tulin harjoittelijaksi, samalla C++-kurssin teoriaosuus vaihtui C-kieleen ja sulautettuihin järjestelmiin. Otin heti asiakseni "näyttää taitoni" ja alkaa korjaamaan bugeja siitä Linuxin päällä pyörineestä pienestä tietokoneesta mikä oli homman alla (mahdoton tehtävä). Se osoittautui osaksi virheeksi, olisin voinut säästää ainakin viikon tekemällä GTK-tutoriaaleja (huonojen) youtube videoiden mukaan vaikka joka päivä klo. 14 jälkeen kun työteho laskee luonnollisesti. Sen sijaan luin dokumenteja ja kyllähän siinäkin oppi mutta puolella teholla. Pitää muistaa tuo kun seuraavan kerran tulee joku täysin uusi asia. Opettelee tekemään sen saman asian vaikka siinä menisi aikaa ja homma näytäisi huvittelulta. Siitä saa kuvan mitä oikeasti tapahtuu ja pystyy alkaa ratkomaan.

Sitten helmikuussa tapahtui ihme, sain korjattua ihan oikean bugin! Sinne meni gittiin! Erittäin iso juttu meikälle, en voi sanoa että GTK-viidakko on selätetty mutta kovasti voiton puolella.

Kokonaisuudessaan hommat maistuu hyvin. Olin (vieläkin koska pelit) kova Windows-harrastaja, mutta vasta Linuxin opettelu on avannut asiota oikeasti. systemctl tai journalctl tulille ja katotaan uusiksi mikä sielä oikiasti tapahtuu. Windowsissa tapahtuu tietty samat jutut mutta kaikki on niiiiiiin paljon hankalammin tarkkailtavissa. Nykyään kotikoneilta löytyy myös Fedorat. Wintoosan ja Linuxin erona voisin sanoa vaikka verkkoyhteyksien asetusten kirjoittamisen. Anoppilassa piru vie etsin sitä oikeaa ohjauspaneelia Win10:stä joulupyhät, mutta Linuxin puolella kirjottelen vain tekstitiedostoon suoraan ja mietin että onko tämä edes laillista.

Olen viimeksi lukenut tätä ketjua joskus viime vuonna ja onneksi aukaisin nyt, sillä tuo sosiaalisuudesta puhuminen osui kyllä aika hyvin. En ole itse kovin extrovertti ja jäi melkein huomaamatta että olen sivuuttanut tämän asian täysin! On kiusallisia tilanteita joissa kävelen jotain vastaan monta kertaa päivässä ja katsotaan kumpikin muualle, koska ei olla tutustuttu. Ei saatana.

Meikällä on joku juttu että tulee tilanteita ettei oikein tiedä mitä sanoa, hörpitään sitä kahvia 10 minuuttia että kumpikaan sanoo mitään. Osaan kyllä puhua joten korjaan tilanteen ensiviikolla.

Parhaassa tapauksessa seuraava osa tarinaa vasta 39v Juniorina keväällä kuukauden päästä.

To be continued....

Ps. Olen aivan varma että tällä forumilla lurkkailee tyyppejä jotka ovat samassa tilanteessa kuin minä olin (jättäny koulut kesken ja nyt vituttaa kun kumminkin elämäntehtävänä on tietokoneet ja kaikki mitä niillä voi tehdä, mutta sitten ei voi tehdä!)

 

[emagdnim]

Onnea matkaan, kyllä ne työt aina löytyy kun jaksaa painaa.

ja käydä haastatteluissa.