Tämä teos ei opeta mitään tiettyä ohjelmointikieltä tai tekniikkaa, vaan yleisesti ohjelmointiin ja arkkitehtuureihin liittyvää ajattelua. Lisäksi mukana on joitain elementtejä "turvallisen" (= kestävän) ohjelmoinnin periaatteista, esim. Assertien käyttöä ja koodin testausta. Kirja on aika kevyt luettava, itse sisältöä ei ole kuin 200 sivua ja sekin on isoa ja ystävällistä tekstiä.

Kirjan keskeinen viesti on pitkälti oman henkilökohtaisen tehokkuuden parantamisessa. On kuitenkin sanottava, että kirjasta ei juuri ole hyötyä, jos etsii nopeita parannuskeinoja - enemmänkin teema on itsensä haastaminen hieman pidemmällä tähtäimellä. Ei tosin niin etteikö kirjan neuvoja voisi soveltaa välittömästikin, mutta monet suositukset ovat pitkäjänteisempiä ja vaativat harkintaa ja soveltamista.

Kirjassa on suuri joukko yksityiskohtaisia "best practises" tyyppisiä toimintaohjeita, joista ohessa muutama keskeisin koodariorientoitunut (kirjassa on myös yleisempiä ideoita, joten projektipäällikkötason ihmisetkin voivat sen mainiosti lukea:

• Avoid the trap of duplicating knowledge
  Suomeksi sanottuna, "copy&paste" on syntiä. Samaa asiaa ei pitäisi olla määriteltynä kahteen paikkaan. Äärimmilleen vietynä tämä tarkoittaa mm. sitä, että tietokanta schema, data-access layer ja dokumentaatio pitäisi kaikki olla automaattisesti synkronoituja, jotta yhdellä muutoksella voidaan päivittää kaikki.
•  Write flexible, dynamic, and adaptable code
  Kirjoita hyvää koodia! Usein koodi kirjoitetaan vain kerran, mutta luetaan monta kertaa, joten on äärimmäisen tärkeää, että koodi on luettavaa. Toisaalta, usein koodia joudutaan myös muokkaamaan, joten sen on oltava helposti muokattavissa.
• Avoid programming by coincidence
  Tunnetko usein tekeväsi jotain tekniikalla "kokeilen kaikkea kunnes se toimii"? Paitsi että näin voi päätyä ratkaisuun, joka ei oikeasti toimikaan, siitä seuraa myös ajanhaaskausta jatkossa, kun joka kertaa pitää kokeilla läpi kaikki vaihtoehdot. Kannattaa perehtyä asiaan kerran syvällisemmin "miksi se toimii näin".
• Bullet-proof your code with contracts, assertions, and exceptions
  Koodista olisi tehtävä selkeästi käytettävää ja varmasti toimivaa. Ohjelmointirajapinnan pitää luvata vain mitä se toteuttaa ja jos sitä yritetään käyttää väärin, siitä pitää ilmoittaa.
• Test ruthlessly and effectively
  Testaa, testaa ja testaa! Koodi ei ole valmis ennenkuin se on testattu. On häikäilemätöntä työtoverien ajan haaskausta jättää järjestelmään koodia, jota ei ole testattu.
• Make your developments more precise with automation
  Automaatiota kannattaa käyttää aina, kun se vain on mahdollista. Kone tekee vähemmän virheitä toistaessaan mekaanista työtä kuin ihminen. Erilaisten koodigeneraattoreiden käyttöä suositellaan vahvasti.

Näiden käytäntöjen takana löytyy "pragmaattinen filosofia", joka voidaan kiteyttää seuraaviin pointteihin:

• Ota vastuu tekemisistäsi. Ajattele ratkaisuja äläkä selityksiä.
• Älä hyväksy huonoa suunnittelua tai koodia. Korjaa virheet heti niitä havaittuasi.
• Kehitä itseäsi jatkuvasti.
• Vaadi muutosta kun se on mielestäsi järkevää.
• Tuota softaa, mikä tyydyttää asiakkaasi, mutta älä mene liiallisuuksiin (tai anna asiakkaan mennä).
• Paranna kommunikointitaitojasi.

Kautta linjan kirjassa korostetaan vastuun ottamista tekemisistäsi. Tämä koskee niin ohjelmoijaa, projektipäällikköä kuin myyjiäkin. Tehdään oma homma niin hyvin kuin mahdollista, mahdollistaen sama myös muille. Eli projektipäällikön pitää tehdä kaikkensa, että ohjelmoijat voivat keskittyä ohjelmoimiseen, ja ohjelmoijien pitää tehdä kaikkensa, jotta projektipäällikkö voi keskittyä projektin hallitsemiseen. Tähän liittyy mm. riittävän informaation antaminen omista tekemisistä ja ongelmista.