Mitä odottaa ensimmäisellä viikolla ohjelmistokehittäjänä

Tiedät, että nautit koodaamisesta, mutta millaista on tehdä se työhön? Mitä voit odottaa ensimmäisellä viikolla?

En voinut kuvitella ensimmäistä viikkoa uudessa työpaikassa. Aloitatko koodaamisen heti? Entä jos he käyttävät kieltä / kehystä, jota et ole oppinut? Kuinka pääset vauhtiin koodikannan kanssa ja tiedät prioriteetit? Onko helppo pelata joukkueessa? Aiotko vain ... avata editorisi ja aloittaa koodaamisen? Entä jos saat jotain pahasti vikaa ja rikot kaiken?

Olen työskennellyt 2 vuotta koodaavassa bootcampissa, ja kuulin samanlaisia ​​kysymyksiä monilta opiskelijoilta. He tiesivät pitävänsä koodauksesta ja rakastivat sitä, mitä he tekivät päivittäin bootcampilla - mutta he halusivat tietää, miltä tuntuu mennä oikeaan työhön.

Tässä viestissä käytän esimerkkejä siitä, mitä tein ensimmäisten päivien aikana viimeisimmässä roolissani yrittääkseni antaa sinulle käsityksen siitä, mitä voit odottaa.

Tausta

Työskentelen täysimittaisena kehittäjänä pienessä yrityksessä. Suunnittelutiimissä on neljä kehittäjää (mukaan lukien minä) ja CTO. Teemme myös tiivistä yhteistyötä tuotteen omistajan kanssa, joka on yksi perustajista. Menin sisään muutaman vuoden koodauskokemuksella.

Kaikki palvelut ovat AWS: llä, ja käytämme NodeJS: ää ja Rubyä.

Päivä 1: Enimmäkseen asennus

Tulin toimistolle klo 9. Kiiltävä uusi MacBook Pro odotti minua pöydälläni, mukana sovittimet ja kaksi näyttöä. Kehitystiimi vei minut ulos aamiaiselle läheiseen kahvilaan, ja kun palasimme, istuin alas ja aloin laittaa laitetta.

Koska olen aiemmin asettanut lukemattomia dev-ympäristöjä työskennellessäni koodaavan bootcampin kanssa, tämä oli melko suoraviivaista eikä kestänyt kauan. Olin kuitenkin asettanut Ruby / Rails-ympäristön omalle kannettavalleni vain kerran, joten osa vei minut hieman kauemmin.

Minulle toimitettiin A4-arkki, jossa luetellaan vaatimukset, versionumerot ja niin edelleen. Sain myös pääsyn useille sivustoille, kuten BitBucket, salasananhallinta, AWS ja Gitlab, ja määritin SSH-avaimet uudelle koneelleni.

Ennen lounasta menin keskustelemaan CTO: n kanssa ja puhuimme yksityiskohtaisesti tuotteesta, arkkitehtuurista sekä tavoitteista ja prioriteeteista, joita kehitysryhmällä on lähitulevaisuudessa.

Lounaan jälkeen kloonasin joitain palveluja, jotka muodostavat sovelluksen, ja aloin tutustua koodikantaan. Onneksi liityin joukkueeseen aikana, jolloin kehitteillä oli uusia, tuoreita osia, mikä tarkoittaa, että minulla ei ollut liikaa koodia, jotta voisin päästä vauhtiin.

Viimeisen parin tunnin ajan istuin yhden vanhempien kehittäjien kanssa, kun hän toteutti ominaisuuden. Käytimme sitä tilaisuutena hänelle opastaa minut sovelluksen osassa ja selittämään, miksi asiat on tehty tietyllä tavalla, ongelmat aiheuttaneet osat ja näkökohdat, jotka saattavat muuttua tulevaisuudessa.

Päivä 2: Testaus

Minulle annettiin tehtävä testata pari toimintoa yhdessä sovelluksen repoista. Uusien palkkatestien kirjoittaminen on loistava tapa tutustuttaa heidät koodipohjaan ja tutustuttaa heidät sovelluksen logiikkaan.

Vietin melko vähän aikaa vain lukemalla koodia, selvittääkseen, miten kaikki toimi yhdessä, ja nähdessäni, voinko seurata logiikan kulkua. Minua kiinnostivat ryhmän valitsemat käytännöt, tapa, jolla koodi oli jaettu, ja tyylivalinnat. Testien kirjoittaminen ei ollut vaikeaa, mutta olen aina varovainen tekemällä ensimmäisen merkkini koodikantaan, jota en ole aiemmin työskennellyt!

En halunnut, että työni pysyisi ulkona, joten yritin tarkkailla ja absorboida tällä hetkellä käytössä olevaa koodityyliä. Jossakin määrin hyvien käytäntöjen, kuten nukkaamisen, käytöstä on paljon apua, mutta on myös vain yleisiä arkkitehtonisia ja tyylillisiä valintoja, joissa nukkaus ei voi auttaa sinua.

Yksi pieni haaste minulla oli tottua tiimin käyttämään Git-työnkulkuun. Jokaisella joukkueella on oma tapansa tehdä asioita: jotkut joukkueet sulautuvat, jotkut joukkueet alkavat uudelleen, jotkut joukkueet tekevät töitä ja toiset eivät, toiset seuraavat tämänkaltaisia ​​suosittuja työnkulkuja ja toiset vain pakottavat työntämään päällikköä tahattomasti. Lisäksi on olemassa sitoutumisviestin ja -kuvan sopimismenettely, tarkistamisprosessi ja niin edelleen.

Kaiken kaikkiaan on paljon ei-eksplisiittisiä "tällä tavalla me teemme asioita". Kun olen käynyt läpi prosessin muutaman kerran, korjannut virheeni ja esittänyt kysymyksiä, se on nyt toinen luonne.

Kirjoitin koko ajan muistiinpanoja muistikirjaan ja pidin koodinpätkiä Bear-nimisessä sovelluksessa. Oli niin paljon tehtävää - miten tehdä asioita, joukkueelle suositeltavat menettelyt, asiat, joita en ollut aiemmin tehnyt, sekä uudet kielet ja kehykset oppia varten.

Minun piti olla todella aktiivinen huomatessani oppimani. Pyysin jokaisen päivän lopussa tai alussa tarkistamaan muistiinpanoni, lisäämään ylimääräisiä selityksiä kiireesti kirjoittamiini asioihin ja tutkimuksiin, joita en ymmärtänyt täysin. Kaikki tämä vie myös jonkin aikaa.

Päivä 3: Spiking AWS

Osana käynnissä olevaa julkaisua meidän oli päätettävä, kuinka rakennamme palvelua. Käytimme AWS: ää, mutta oli valittavissa EC2-ilmentymän käyttäminen, mikä olisi yksinkertaisin valinta, koska se on vain palvelin pilvessä, joka käyttää sovellustasi, tai jotain hiukan miellyttävämpää, kuten Elastic Container Service. ECS: n etuna on, että se hallitsisi useiden EC2-esiintymien skaalausta ja olisi siksi hyvä vaihtoehto tulevaisuutta varten. Mutta se ei ollut toistaiseksi täysin välttämätöntä.

Tämän vuoksi minulle annettiin (vapaaehtoisena) tehtävä selvittää, kuinka helppoa palvelumme olisi ottaa käyttöön ECS: ssä. Piikkiminen tarkoittaa vain kokeilemista jotain toteutettavuuden tutkimiseksi. Jos se oli vaikeaa, se ei ollut sen arvoista, koska se oli tulevaisuuden optimointi, jota emme kipeästi tarvinneet juuri nyt.

Tämä merkitsi paljon oppimista minulle, koska en ollut aiemmin käyttänyt Amazonin ECS: ää, ja sovellus oli Rails-sovellus, ja olin paljon vähemmän perehtynyt koko Ruby / Rails-ekosysteemiin. Olin viettänyt ehkä yhteensä 30 tuntia Rubyn oppimisessa ennen liittymistä yritykseen, koska tiesin, että se oli osa heidän pinoaan, mutta tuskin kosketin Railsia. Lisäksi tehtävään liittyi vähän työtä Dockerin kanssa, mikä oli myös minulle uutta.

Tekninen johtajani sai minut aloittamaan periaatteessa 1 tunnin intron Dockerille, joka oli erittäin hyödyllinen. Sieltä vietin suurimman osan päivästä luomalla uuden Rails-sovelluksen ja seuraamalla erilaisia ​​artikkeleita, asiakirjoja ja esimerkkejä siitä, voisinko saada asian toimimaan ECS: ssä. Olen melkein päässyt sinne, mutta tietokantaintegraation saaminen toimimaan osoittautui kompastuskiveksi. Oli vain niin paljon uutta.

Olen varma, että jollekulla, joka tuntee joko ECS: n tai kiskot, ei olisi ollut niin paljon ongelmia. En voinut tulla pois sanomalla, että prosessi oli objektiivisesti vaikea. Se oli kova minulle , mutta se ei tarkoita, että se oli vaikea kaikille.

Ei kovin tuottava päivä käytettävän koodin tai tulostuksen suhteen, mutta minusta tuntui oppineen paljon ja tästä näkökulmasta, ja se oli hienoa.

Päivä 4: Pariliitos ja mentorointi

Saavuin toimistolle klo 8, ja kun odotin muiden saapumista, kävin osassa Docker-kurssia, jota olin katsellut Pluralsightissa. Olin edelleen innokas lopettamaan eilisen piikin, mutta huomasin, että tarvitsin enemmän pohjaa ainakin yhdelle uudesta tekniikasta, jonka kanssa työskentelin.

Vietin kurssilla noin tunnin, ennen kuin lisää ihmisiä saapui toimistoon ja aloimme päättää kuka teki mitä. Toinen uusi kehittäjä, joka oli aloittanut vähän ennen minua, oli juuri palannut lomalta. Päätimme yhdistää yhdessä tehtävän. Rakensimme uutta ominaisuutta Rails-sovellukseen. Tämä oli melko yksinkertainen tehtävä, mutta Rails oli uusi meille molemmille, joten oli hienoa työskennellä sen läpi yhdessä. Kun tarvitsemme jotain selitettävää, kysyisimme yksinkertaisesti joltakin muulta kehittäjältä joko henkilökohtaisesti tai Slackin kautta. Meillä oli hienoja keskusteluja tällä tavalla, ja aloin ymmärtää, kuinka Rails toimii.

Iltapäivällä minulla oli mentorointi teknisen johtajan kanssa, joka oli antelias, koska minulla oli jo edellinen päivä yksityinen Docker-luokka! Mentorointi on tilaisuus esittää kysymyksiä, käydä läpi ongelmia yhdessä, oppia jotain yhdessä tai vain valita jonkun aivot. Tiedonsiirto on erittäin hyödyllistä.

Minulla oli paljon outoja kysymyksiä tietokantatavaroista ja kiskoista, mutta valitettavasti minulla ei ollut yhtä tavoitetta ensimmäiselle istunnolle. Luulen vain, etten ollut varma mitä odottaa. Seuraavissa istunnoissa olen pyytänyt mentoriani näyttämään minulle, miten tehdä jotain erityistä, kuten määrittää NGINX-palvelin tai määrittää EC2-ilmentymä pääsyyn tietokantaan - asioita, jotka hän jo tietäisi, mutta minun vie paljon kauemmin ulos omasta.

Päivä 5: Kokoukset ja sulautumiset

Monet ohjelmistotiimit käyttävät stand up -kokousten (usein päivittäin), säännöllisten takautuvien näkymien (työskentelykäytännöistä tai teknisistä kysymyksistä) ja suunnittelutilaisuuksien järjestämistä työnkulunsa korkealle tasolle yhdistettynä jonkinlaiseen seurantatyökaluun, jossa työ tapahtuu edistyminen ja jäljellä oleva työ voidaan visualisoida.

Tiimimme ei ole erilainen, ja meillä on suurin osa suunnitelluista kokouksistamme perjantaina. Kuten monien joukkueiden tavoin, kokouksissamme painotetaan sitä, miten olemme työskennelleet ja mitä olemme saavuttaneet, ratkaisemaan kaikki ongelmat tai esteet yhdessä ja tunnistamaan ja suunnittelemaan tulevat työt niin, että meillä on aina jotain etukäteen olemme valmiita siirtymään.

Menemme myös aamiaiselle sitomaan, mikä on mahtavaa!

Kaiken kaikkiaan suurin osa aamusta käytettiin näihin toimintoihin. Minulla oli vähän panosta, koska pääsin yhä ympäri kaikkea terminologiaa ja tuotteen rakennetta, ja olin aina noin lauseen takana yrittäen saada kiinni juuri sanotusta. Muistan, että ensimmäisen viikon aikana tunsin vain, että aivoni sulivat, kun yritin pitää mielessäni kaikki arkkitehtuurin eri osat yhdessä (se paranee ajan myötä, joten älä huoli!).

Iltapäivällä parini ja minä pystyimme lopettamaan työn, jonka kanssa olimme työskennelleet, pyytämään koodin tarkistusta, tekemään muutoksia ja avaamaan pyynnön yhdistää työmme sovellukseen. Emme käyttäneet, koska se oli perjantai-iltapäivä, mutta teimme seuraavana maanantaina. ?

Kiitos lukemisesta, toivottavasti tämä artikkeli antoi sinulle käsityksen siitä, miltä ensimmäinen viikko kehittäjänä saattaa näyttää.

Haluaisin kuulla kommenttisi ja kokemuksesi!