Avainsana: koodaus

do while koodi <3

Subversion ja versionhallinta

Kaikki enemmän tai vähemmän ohjelmointiin tutustuneet varmasti tietävät, että koodia on kätevää säilyttää versionhallinnassa. Pieniäkin projekteja on suhteellisen vaivatonta ja hyödyllistä säilyttää esimerkiksi Subversion-versionhallinnassa, vaikkapa ihan vain omalla työasemalla sijaitsevassa repositoryssä.

Versionhallinta on tietenkin omimmillaan isommissa projekteissa, joissa toteuttajia on useita ja repository sijaitsee keskitetysti jollain palvelimella. Versionhallinnan ei tarvitse rajoittua pelkästään sovelluskoodiin, vaan sen voi ulottaa muihinkin muuttuviin ja versioitaviin projekteihin, kuten esimerkiksi PL/SQL-paketteihin ja asetustiedostoihin.

Coding Horror -blogi ohjeistaa kätevästi Subversionin (SVN) asennuksessa omalle koneelle ja kattaa myös hieman versionhallinnan perusteita. Subversion onkin kohtalaisen hyvin tuettu eri ohjelmien toimesta ja sille on saatavilla useita eri ohjelmistoja eri alustoille kuten TortoiseSVN, SubCommander ja Eclipseen saatava Subversive. Muista ohjelmista mainittakoon Trac, joka tarjoaa projekteille viritellyn wikin, tikettiträkkerin ja liitynnän Subversioniin.

Jos versionhallinta yleisesti ei ole tuttu asia, kannattaa vilkaista visuaalinen opastus versionhallintaan ja sen toteuttamisesta keskitettynä mallina Subversionilla löytyy kattava Version Control with Subversion -kirja.

Vaihtoehtona hajautettu versionhallinta?
Versionhallintaa voi toteuttaa myös hajautettuna mallina, kuten Linuxin Kernelin kehittämisessä Gitiä käyttäen. Muita hajautettuja malleja ovat muun muassa Mercurial (mm. Mozilla) ja Bazaar (mm. Ubuntu). Keskitettyyn malliin verrattuna hajautetussa mallissa on esimerkiksi jokaisella kehittäjällä oma paikallinen repository. Hajautetuista lähteistä tulokset yhdistetään erilaisin perusteilla, kuten määrättyjen projektijäsenten päätöksillä mitkä muutokset siirretään eteenpäin tai sitten voidaan käyttää keskitetyn mallin tapaa. Hajautetun mallin järjestelmät ovat yleistymässä, mutta muutos keskitetystä mallista hajautettuun vaatii totuttelua. Pitämällä paikallista repositoryä, päästään aina käsiksi historiatietoon, sekä saadaan versionhallinnan tarjoamat edut ilman koodin yleisesti julkistamista.

Versionhallinta onkin osaltaan myös uskonnollinen kysymys samalla tavalla, kuten esimerkiksi käyttääkö vimiä vai emacsia, KDE:tä vai Gnomea tai Linuxia vai Windowsia. Erilaisista versionhallintamalleista löytyykin vahvoja mielipiteitä, kuten Linus Torvaldsin esitys hajautetun mallin Gitistä osoittaa. Yleisesti katsottuna tärkeintä kuitenkin on, että käytössä on edes jokin versionhallintajärjestelmä. Oli se sitten Subversion, Git, Mercurial, Bazaar tai vanha kunnon CVS.

Subversionilla alkuun
Tavallaan Subversionin ja yleisesti ottaen keskitetyn versionhallinnan voisi sanoa olevan jo hieman vanhentunutta, mutta Subversion tarjoaa tällä hetkellä helposti lähestyttävän ja hyvin tuetun kokonaisuuden versionhallintaan.

Toisaalta taas Subversionissa on heikkouksiakin, joten muihinkin vaihtoehtoihin kannattanee tutustua, kun perusteet ovat hallussa. Etenkin hajautettu malli vaikuttaa ihan kätevältä.

Subcommander Subcommander Subcommander
Trac TortoiseSVN

Ohjelmointi kuin urheiluharrastus, harjoittelulla parempiin tuloksiin

Joulun kiireiden keskellä on hyvä pysähtyä ja irtautua arkielämän hössötyksistä ja syventyä hyvän kirjallisuuden ääreen tai tietoteknisten harrastusten pariin. Vaihtoehtoja ajanvietteeksi on monia ja Codeulate-blogi tarjoaa vaihtoehdoksi harjoittelua: ohjelmoinnin harjoittelua. Vaikka ohjelmointitaidot olisivatkin jo hallussa valitsemallasi ohjelmointikielellä, on hyvä silti panostaa harjoitteluun. Ohjelmointia voi käsitellä kuin mitä tahansa urheilu- tai musiikkiharrastusta; paremmaksi kehitytään vain harjoittelemalla.

Ohjelmointia voi harjoitella erilaisilla tavoilla ja Internetissä on tarjolla erilaisia sivustoja, jotka tarjoavat älynystöreille harjoitteita. Project Euler lähestyy aihetta matemaattisten ongelmien kautta ja ratkaisut eivät vaadi tutkintoa matematiikasta. Python Challenge vastaa tarjoamalla 33-tasoisen haasteen. Molemmilla sivustoilla on ongelmien lisäksi tarjolla ratkaisut ja keskustelufoorumi muiden ohjelmoijien ratkaisujen tutkimiseen. Vastaavasti 99 Prolog -ongelmaa keskittyy loogiseen ongelmanratkontaa ja tarjoaa ratkaisut Prologilla toteuttuna. Ongelmia voi tietenkin ratkoa haluamallaan ohjelmointikielellä.

Ohjelmoinnin harjoittelemisessa ei kuitenkaan ole kiire ja teokset, jotka mainostavat ”Opi ohjelmointikieli X 21 päivässä” -otsikolla pitäisikin itseasiassa otsikoida ”Opettele ohjelmoimaan 10 vuodessa”. 3 päivässä, viikossa tai kuukaudessa saa vain pintapuolisen käsityksen jostakin ohjelmointikielestä ja todellinen hallitseminen ja käsittäminen tapahtuu pidemmällä aikajänteellä. Tutkimusten mukaan jonkin tietyn aiheen oppiminen ja hallitseminen vie 10 vuotta, oli se sitten shakin peluu, musisointi, maalaaminen, tennis tai ohjelmointi.

Oikotietä parempiin suorituksiin ei ole ja kuten monissa muissakin harrasteissa ja taidoissa, myös ohjelmoinnissa kehitytään paremmaksi vain harjoittelemalla ja mahdollisesti harjoittelemalla laaja-alaisesti. Yhtäläisyyksiä löytyy myös siinä, että toiset vain ovat parempia kuin toiset ja vain lahjattomat treenaavat.

Jos pelaaminen on liian helppoa, rakenna Guitar Hero -botti

Pelien pelaaminen on usein kovin mekaanista ja loppujen lopuksi kohtalaisen yksinkertaista, mutta viihdyttävää ajanvietettä. Jos pelaaminen kuitenkin tarjoaa liian vähän haasteita, kannattaa esimerkiksi opettaa tietokone pelaamaan. Eräänä päivänä Xbox 360:lla Guitar Hero 2:sta pelatessaan Kevin Herron päätti toteuttaa ainakin yhden jänskän projektin sinä kesänä ja lopputuloksena oli Tom Hannu -Guitar Hero botti. Tietokoneohjelma, joka ensin opettelee Guitar Hero -pelin kappaleen ja tämän jälkeen soittaa sen.

Tom Hannun rakenne on selkeä ja toteutuskin kohtalaisen selkeä. Kokonaisuus jakautuu kahteen osaan: kitaraohjaimeen liitettyyn rautapuoleen ja kappaleiden opetteluun ja soittamiseen liittyvään ohjelmistopuoleen. Kitaraohjaimeen liittyvä puoli on toteutettu käyttämällä Parallax BASIC Stamp 1 Project -mikrokontrolleria, jossa on 4 MHz prosessori, 16 tavua muistia ja 8 I/O liitintä. Käytännössä mikrokontrolleri siis liitetään peliohjaimen nappeihin, jonka jälkeen voidaan välittää komentoja tietokoneelta sarjaliitäntää käyttäen ja painella soittimen nappeja.

Soittavan botin ohjelmistopuoli koostuu kolmesta erillisestä ohjelmasta: silmät, aivot ja sormet. ”Tomin silmät” -ohjelma toimii konenäkönä, jolla analysoidaan harjoitusmoodissa pelin soittovideo ja kerätään talteen kappaleen nuottikartta. ”Tomin aivot” -ohjelmalla tarkastellaan kerätty nuottikartta kappaleesta ja samalla voidaan tarvittaessa muokata nuotteja. Itse soittaminen tapahtuu ”Tomin sormet” -ohjelmalla, jolla voidaan lähettää napin painallus Xbox 360:n kitarasoittimelle ja soittaa kappaleen nuottikartta.

Tom Hannun projektisivuilta löytyy kuvia Tom Hannu -botista ja videoita ohjelmien toiminnasta. Lopputulos näyttää hyvältä, joskin onko pelaaminen enää hauskaa, jos tietokone tekee sen puolestasi. Sivuilta on lisäksi saatavilla lähdekoodit Tomin silmille ja aivoille, mutta Tomin sormia ei ole saatavilla. Ohjelmat on toteutettu käyttämällä Mac OS X:n frameworkkeja ja Xcodea.

Oivaltavaa ja varmasti erittäin opettavaista harrastelua pelaamisen sivutuotteena.

LTY:n .NET Sovelluskehitys -intensiivi, päivät 3, 4 ja 5

Päivät venyivät pitkiksi, kun tietotekniikan opiskelijat pääsivät Visual Studioon sisään ja koodia tulevaa sovellusta varten alkoi syntymään. Useat ryhmät olivat ideoinnin vähyyden ja tiukan aikataulun takia päätyneet kehittämään jonkinlaista kurssin harjoitustyönpalautus -web-sovellusta. Muita ideointeja oli muistiinpano -webtyökalu, opiskelumateriaalin tarjoaminen webin avulla, prosessorin muistioperaatio -simulaattori, kielenopiskelu -sovellus ja tietojen hakeminen web-sivulta.

Kurssin puolesta keskiviikkona ja torstaina oli muutamia demoja Visual Studion käytöstä ja valmiista komponenteista. Muutamat elementit sivulle ja käyttäjän autentikointi oli valmis. Osaltaan kätevää, mutta toisaalta valmiit elementit ja kehitysympäristö pakottivat tiettyyn toteutustyyliin. Ainakin Web-sovelluksen ja osittain tietokantojen näkökulmasta valmiit elementit tuottivat päänvaivaa. En ollut Googlen mukaan ainut, joka kirosi Sitemapin muotoilua. Valmiit elementit kuitenkin mahdollistivat nopean kehittämisen ja valmista jälkeä syntyi. Aikaa olisi vain voinut olla enemmän käytettävissä, vaikka päivät venyivätkin seuraavan päivän puolelle.

Perjantain palautustilaisuudessa valmiusasteet vaihtelivat, mutta aika hyvin oli valmista saatu tehtyä. Ulkoasun ja käytettävyyden viimeistely uupui lähes jokaisessa työssä, joka tosin oli oletettavaakin muutaman päivän projektia ajatellen. Oman ryhmäni Courserator -projekti liittyi harjoitustöiden palautukseen ja teknisesti kaikki ominaisuudet saatiin toteutettua. Myös ulkoasuun sijoitettiin hieman muita ryhmiä enemmän työaikaa, sillä viimeistelty työ luo hyvän mielen, eikä sen toteuttamiseen juuri aikaa mene. Projektista myöhemmin muutamia kuvia, kunhan pääsen takaisin kotiin.

Kurssin viimeisenä päivänä projektien esitystilaisuuden jälkeen myös palkittiin parhaana ideana ”Muistiinpanotyökalu”, teknisestä toteutuksesta ”Adaptive English learning application” ja ”Kurssien sivuilta tapahtumien parsettaminen omalle sivulle” ja ryhmien lisäksi palkittiin muutama osallistuja Code Camp -hengestä ja sisukkuudesta. Muista erottuvalla idealla pääsi pitkälle, vaikka toteutukseltaan moni ”harjoitustyön palautustyökalu” oli teknisesti toimivampi. Kielenopiskeluun liittyvä toteutus oli kyllä myös ideansa lisäksi teknisesti hyvä.

Kokonaisuudessaan .NET Sovelluskehitys -intesiivi oli hyvä kurssi, joskin Code Camp -henkisesti alkuviikon alustukset ja muutamat demot olisivat voineet keskittyä enemmän ratkaisuihin kuin arkkitehtuuriin ja sen yksityiskohtiin. Kehittäessä sovellusta tuli tutustuttua Visual Studioon, sen toiminnallisuuteen ja komponentteihin, mutta kehitysympäristön hallitsemiseksi hyvin, tarvittaisiin hieman lisää koodaamista.

Intensiivikurssista on vielä edessä viiden sivun raportin kirjoittaminen, joka on ”Imagine Cup” -kilpailua varten tähdätty, tarkoituksena kuvata idea ”Technology & Education” -aihepiirin projektista. Raporttia ei ole pakko lähettää kilpailuun ja luultavasti emme sitä sinne lähetä.

Päivitys 15.3.2007:
.Net Sovelluskehitys -intensiivikurssi sai myös huomiota paikalliselta medialta, kun Etelä-Saimaan toimittaja kävi paikalla kuvaajan kanssa. Tapahtumasta tehty juttu löytyy Etelä-Saimaan verkkosivuilta.

Microsoftin puolelta järjestävänä tahona mukana ollut Aali Alikoski kirjoittaa tapahtumasta blogissaan, josta löytyy myös muutamia kuvia.

LTY:n .NET Sovelluskehitys -intensiivi, päivä 2

.NET Sovelluskehitys -intensiivin toinen päivä alkoi mikroluokassa ohjelmointiympäristöön tutustumisella. Luokkaan oli asennettu valmiiksi Visual Studio 2005, mutta kaveri oli tietenkin onnistunut valitsemaan juuri yhden niistä neljästä koneesta, joissa Visual Studion asennus ei kunnolla toiminut. Onneksi ohjelmointiympäristön debug-ominaisuuskin saatiin kuntoon ylläpidon suoritettua noin pari tuntia yhteensä kestäneen korjaus- ja service pack -asennuksen.

Sillä välin kun muut leikkivät Visual Studiolla, ehdin todeta Monodevelop -ohjelman asentamisen OS X:lle mahdottomaksi. Fink ei löytänyt peileiltä haluttuja paketteja Gnome-työpöytäympäristön asentamiseksi. Kai ohjelman voisi asentaa käsinkin, mutta sivuilla olevat ohjeet ja lista useista paketeista, joita pitäisi kääntää tietyillä optioilla, ei oikein herätä innostusta. Lisäksi sivuilla mainittu MacUX -projekti Monodevelop -asennuspaketin kasaamiseksi OS X:lle, on kirjoitusten mukaan jäämässä kesken. Pitää vielä yrittää Finkin kautta asennusta, asentamalla ensin Gnomen eri lähteistä (stable) ja tämän jälkeen Monodevelopin (unstable).

OS X:lle tarjolla olevien .NET-järjestelmän -kehitystyökalujen suhteen on harmillista, että Monodevelopin asentaminen OS X:lle on turhan hankalaa ja muiden ohjelmien tuki ohjelmoijalle on olematonta. Vaikka XCode:lla voi ohjelmoida C#:ia, on sen käyttäminen aloittelijan lähtökohdista kohtalaisen hankalaa ilman minkäänlaisia ohjelmointiapuja. Yhtä hyvin voisi ohjelmoida vimillä. Leikin kuitenkin XCoden lisäksi hieman Interface Builder -ohjelmalla ja helpostihan Cocoa# -käyttöliittymä rakentui.

Päivä sisälsi myös katsauksen .NET-järjestelmän tarkempiin ominaisuuksiin ja toiminnallisuuteen ja näimme muutamia demoja. Ei mitään sinällään erikoista. Mainostaakseen Imagine Cupia Microsoft tarjosi jokaiselle kilpailusivustolle rekisteröityneelle yhden vapaavalintaisen kirjan ja pelin. Valitsin vaihtoehdoista ”ASP.NET 2.0 Applications: Advanced Topics” -kirjan ja ”Gears Of War” -pelin Xbox 360:lle, vaikka en kyseistä konsolia omistakaan. Pitänee kai harkita ostamista :)

Päivän lopuksi käsiteltiin kurssin arvosteluperusteita ja aihepiiriä, johon liittyen pitäisi perjantaihin mennessä koodata jonkinlainen Windows- tai Web-pohjainen sovellus. ”Technology & Education” -teema on sinällään läheinen, mutta järkevän sovelluksen kehittäminen lyhyessä ajassa tuo omat haasteensa. Aivan yksin ei sovellusta tarvi kehittää, vaan päivän aikana muodostettiin 3-4 hengen ryhmiä. Varsinaisen ohjelman jälkeen ryhmät jäivät ideoimaan voittajasovellustaan tähtäimessään perjantain koodijulkistus ja palkinnot. Voi olla hankalaa kehittää toimivaa ideaa näin lyhyessä ajassa, joka jaksaisi kantaa myös mainostettuun Imagine Cupiin. Eihän sitä tosin koskaan tiedä.

Huomenna ja torstaina aamupäivät on varattu luennoille ja iltapäivällä jatketaan koodausta. Aikaa ei juuri tuhlattavaksi ole.

LTY:n .NET Sovelluskehitys -intensiivi, päivä 1

Tänään alkoi Lappeenrannan teknillisen yliopiston järjestämä .NET Sovelluskehityskurssi, joka toteutetaan intensiivinä 5.3 – 9.3.2007 Code Camp -periaatteella. Ensimmäisen päivän ohjelmana oli Microsoftin sovelluskehityskiertue, joka käsitti katsauksen .NET kehitysympäristöön, ominaisuuksiin ja mahdollisuuksiin. Kurssi toimii myös lähtölaukauksena Imagine Cup:iin.

Microsoftin sovelluskehityskiertue oli jotakuinkin samanlainen kuin vuosi sitten, kun sellaisessa kävin. Alkuun yleisesti aiheesta, Imagine Cup:n mainostusta, jonka jälkeen käsiteltiin .NET-järjestelmää kohtalaisen yleisellä tasolla ja luotiin katsaus mitä .NET 3.0 tuo tullessaan. Lisäksi yhteistyökumppani kertoi työelämän tarpeista ja haasteista sovelluskehityksen parissa työskenneltäessä. Aiheiden välissä pidettiin sopivasti kahvitaukoja, jotka Microsoft ystävällisesti tarjosi ja jonka laskuun myös lounas meni. Tietenkin Microsoftin Visual Studio -kehitystyökalua ja kumppanuusohjelmia mainostettiin riittävästi. Kyllähän se Visual Studio ihan kivalta ja toimivalta näytti. Esitysten jälkeen ilta jatkui LTY:n rantasaunalla illanvieton ja vapaamuotoisen keskustelun merkeissä ja tarjolla oli syötävää, juotavaa ja sauna.

Tapahtuma oli ihan mukava ja esityksiäkin jaksoi kuunnella, vaikkakin aiheita käsiteltiin hieman liian yksinkertaisesti. .NET-ympäristöstä sai jonkinlaisen kuvan, mutta joitakin aiheita olisi voinut käsitellä hieman syvemmin ja jättää toisia aiheita, kuten C# esimerkkien rakentamista, hieman vähemmälle. Arkkitehtuuri ja mahdollisuudet käsiteltiin aika pintapuolisesti ja kokonaiskuva jäi aika hajanaiseksi; paljon kivoja ominaisuuksia, hienoja käyttöliittymiä, helppoa koodigeneroimista, erilaisia rajapintoja ja hyvät kehitystyökalut. Myös Vistan karkkimainen käyttöliittymä ja toiminta tulivat tutuiksi.

Huomenna intensiivikurssi jatkuu luennoilla, demoluennoilla, aiheen valinnalla ja koodaamisella. Asensinkin jo Mac OS X:lle Mono -ympäristön, XCode:en C# -pluginin. ASP.NET -sovelluksia voi ajaa Mono:n mukana tulleen XSP -palvelimen avulla. Kaikki tarvittava löytyi Mono -projektin sivuilta, mutta ympäristön voi asentaa myös Darwin Portsin kautta. Peruskoodit kuten C# HelloWorld.cs, Cocoa# -HelloWorld.app ja ASP.NET HelloWorld.aspx toimivat, joten asennus onnistui. Monon, C# -ympäristön ja XCoden käytöstä lisää myöhemmin.

Kurssilla koodausympäristönä toimii Visual Studio 2005, mutta oma Mono -ympäristö Mac OS X:ssä helpottaa ominaisuuksien testaamista ja samalla voi vertailla koodin toimivuutta .NET ja Mono -ympäristöissä. Nopeasti testattuna XCoden C# -pluginin tuki ohjelmoijalle oli olematonta, joten ohjelmointiympäristöjen vertailu ei ole mielekästä. Jos omistaisin Macbookin voisin ajaa Windowsia ja Visual Studiota Parallelin kautta ja silti nauttia OS X:n mukavuuksista.

Saa nähdä kuinka ahdasta huomenna mikroluokkaan ja koneiden äärelle tulee, sillä luokka on kohtalaisen pieni ja innokkaita koodaajia ensimmäisen päivän perusteella runsaasti.

Paremmaksi ohjelmoijaksi

Coding Horror kirjoittaa, kuinka tulla paremmaksi ohjelmoijaksi ohjelmoimatta ja esittelee ajatuksen, että keskinkertainen ohjelmoija ei kokemuksen lisääntyessä muunnu taianomaisesti hyväksi ohjelmoijaksi. Hyvät ohjelmoijat tuntuvat omaavan luonnollisen kyvyn ohjelmointiin jo alusta alkaen. Asia ei tietenkään ole aivan näin yksiselitteistä ja esimerkiksi harjoittelemalla päästään parempiin tuloksiin.

Tiedetään, että on leveä kuilu ohjelmointia osaavien ja sitä osaamattomien välillä, mutta sama pätee myös ihmisiin, jotka osaavat ohjelmoida; hyvien ja keskinkertaisen ohjelmistokehittäjien välillä on suuri ero.

Jeff Atwood, Coding Horror -blogin kirjoittaja, lainaa Programmers at Work -teosta, jossa haastatellaan kuuluisia ohjelmoijia vuoden 1986 tienoilla.

Does accumulating experience through the years necessarily make programming easier?

Bill Gates: No. I think after the first three or four years, it’s pretty cast in concrete whether you’re a good programmer or not. After a few more years, you may know more about managing large projects and personalities, but after three or four years, it’s clear what you’re going to be. There’s no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight. I can talk to somebody about a program that he’s written and know right away whether he’s really a good programmer.

Jeff Atwood puoltaa Bill Gatesin ajatuksia ohjelmointitaitojen kehittymisestä ja on itsekin todennut, että hyvä ohjelmointitaito joko omataan, tai sitten sitä ei ole. Mikä sitten tekee ohjelmoijasta paremman ohjelmoijan, jos ei kokemus? Onko taitojen kehittäminen mahdotonta?

Coding Horror -blogin kirjoituksen mukaan paremmaksi ohjelmoijaksi kehitytään omaamalla ja kehittämällä intohimo kaikkeen muuhun ohjelmoinnin ympärillä. Et voi kehittyä paremmaksi ohjelmoijaksi vain pelkästään ohjelmoimalla, vaan voit vain täydentää ja parantaa jo olemassa olevaa ohjelmointitaitoasi laajentamalla sitä. Paremmaksi ohjelmoijaksi kehittymiseen tarvitaan oppimista ja kiinnostusta käyttäjistä, alasta ja bisneksestä. Mitä enemmän olet kiinnostunut eri asioista, sitä parempaa tulee työsi olemaan.

You’ve been haacked -blogi vastaa Coding Horrorin kirjoitukseen otsikolla ”Paremmaksi ohjelmoijaksi ohjelmoimalla paremmin”. Blogin kirjoittaja Phil Haack on samaa mieltä Jeff Atwoodin kanssa, että suurten kuvioiden ymmärtäminen on tärkeää etenemisessä hyväksi ohjelmistokehittäjäksi, etenkin jos olet ohjelmointitaidoissa 99 prosentin tasolla. Kuitenkaan useimmat ohjelmistokehittäjät eivät ole 99% tai edes 90% tasolla ja täten pystyvät kehittämään ohjelmointitaitojaan edellä mainittujen tärkeiden taitojen lisäksi.

Phil Haack ei tosin ole vakuuttunut, että ohjelmointitaitojen kanssa synnytään, sillä väitteen tueksi ei ole empiirisiä todisteita. Voiko ohjelmoija siis nousta 50% tasolta 90% tasolle? Haack kirjoittaakin, että viimeaikaisten tutkimusten mukaan uskomus ”synnynnäisiin lahjoihin” on vailla kovia todisteita väitteen tukemiseksi. Scientific American artikkeli ”The Expert Mind” toisaalta puoltaa Atwoodin ajatusta, että henkilön kokemus ei vaikuta suorituskykyyn, mutta lisää yhtälöön suunnitelmallisen opiskelun ja harjoittelemisen.

Suunnitelmallisella opiskelulla ja harjoittelulla ohjelmoija voi nostaa itsensä keskinkertaisuudesta hyväksi ohjelmoijaksi. Kehittymisessä ei ole kyse ohjelmoinnin määrästä, vaan ohjelmoimisesta paremmin. Mitä enemmän ja paremmin, sen parempi. Useimmilla ohjelmoijilla on vielä tilaa kehittää ohjelmointikykyjään ja ohjelmointiin liittyviä taitojaan. Ohjelmoijan osaamat oheistaidot erottavat hänet toisista ohjelmoijista ja lisäävät ohjelmoijan arvoa enemmän, kuin kehitys ohjelmointitaidoissa. Ohjelmointitaidot eivät rakennu pelkästään syntaksin, kontrollirakenteiden tai muiden teknisten ominaisuuksien osaamisesta.

Ei liene yllätys kenellekään, että harjoittelulla ja suunnitelmallisuudella kehitytään paremmaksi halutussa taidossa. Oli kyse sitten hyvää fyysistä kuntoa vaativista urheilulajeista, älykkyyttä vaativista peleistä, loogista päättelyä sisältävistä tehtävistä tai tässä tapauksessa ohjelmoinnista. Sisäinen lahjakkuus tai taipumus tiettyihin ominaisuuksiin auttaa tietylle tasolle pääsemistä, eikä kaikki välttämättä saavuta harjoittelemallakaan korkeaa tasoa, kuten urheilija suomen- tai maailmanmestaruutta. Hyväksi kehitytään kuitenkin vain harjoittelemalla, oli lahjakkuutta tai ei.

Toisaalta Atwoodin ja Haackin kirjoitusten kommenteissa heräteltiin kysymystä, miten määritellä hyvä ohjelmoija ja mikä tekee toisista ohjelmoijista parempia kuin toiset. Miten mitata koodia ja mihin verrata lopputulosta? Koodi ei ole samalla tavalla fyysinen saavutus, kuten urheilutulokset, joita voisi helposti vertailla. Tietenkin on erilaisia mittareita ja keinoja, joita koodeihin voi soveltaa.

On kuitenkin selvää, että jos ohjelmoimme enemmän, paremmin ja omaamme intohimon ohjelmointiin liittyviin asioihin, kehitymme kohti parempaa ohjelmoijaa.