Guarda, vere materiale almeno per poter dire "Ok, ho un punto da cui iniziare" di certo male non mi fa, almeno ho anche modo di capire se è una cosa per cui posso essere portato o no (come ho già avuto modo di dire non sono digiuno di programmazione dall'alto ( !???) del mio diploma informatico, seguito da mezza laurea informatico, seguito da programmatore elettronico di sistemi di protezione elettrici 
).
Ti ringrazio ancora anche solo per il "pensiero" 
Tutto sta ad avere un progetto da curare in cui puoi applicare e sviscerare immediatamente le conoscenze apprese, secondo me. Possibilmente ambizioso e difficile. Mica devi concluderlo, ma se non è difficile non impari abbastanza 
(cut cut cut)
Butto li' la mia sul discorso di StM, perche' per come la vedo io, a leggere una roba del genere mi si rizzano i capelli.
Mentre la lista delle cose da sapere stilata dal buon Monopoli e' piu' che completa, la prima cosa che domanderei in sede di colloquio e' "sai finire quello che inizi?".
Nella mia carriera di programmatore (di videogiochi e non) una delle cose che sento piu' spesso e' "sisi', questa cosa l'ho finita, mi manca solo...", e la mia risposta tipo e' che allora NON e' finita.
Dovessi valutare io le cose, preferisco un progettino piccolo e poco ambizioso ma finito che non una roba complicata fatta per tre quarti.
La skill "saper finire le cose" e' una di quelle che - soprattutto nel campo della programmazione dei vg - considero fra le piu' importanti.
Questo perche' quando si lavora sui PC ad applicativi "normali", non e' raro finirli per tre quarti, e poi "massi', lo patchamo dopo". Quando lavori su un videogioco e' diverso: se su PC si puo' ancora ancora fare, su DS o su PS2 non si patcha niente. Quando un gioco e' finito, deve essere finito davvero.
Un gioco "finito ma...", quando va in submission per l'approvazione, lo stroncano, il che vuol dire che quel gioco non esce. Quando va bene, la cosa si risolve nel dover tirare fuori un po' piu' di denaro in stipendi e nell'uscire in ritardo (o nel momento sbagliato); quando va male, sono cause con il publisher e studi che chiudono per mancanza di fondi.
Inoltre, un altro fatto importante e' che spesso non si puo' o non si sa valutare la bonta' di un'interfaccia (nei termini di "interfaccia di classe C++/classe Java/set di funzioni pascal/quel che e'") di quello che si e' realizzato finche' non lo si utilizza. Imparare a scrivere buone interfacce e' importante nei grossi progetti e in ogni situazione in cui si lavori in team.
Per intenderci: io posso scrivere della roba figa che spacca i culi, ma se lavoro con Monopoli e lui diventa scemo per usarla, in quello che ho scritto qualcosa non va. E si impara a scrivere interfacce solo guardando quelle degli altri con occhio un po' critico, e provando a utilizzare le proprie.
Infine, nella mia testa, il codice serve a risolvere dei problemi, e un problema risolto per tre quarti non e' un problema risolto del tutto. Il quarto restante magari e' solo boilerplate code, mettere le chiamate dove servono; ma spesso, anche se sembra, non e' cosi' ed e' solo al momento di far incastrare le cose che si scopre che in realta', le cose non si incastrano. E se anche si incastrano, spesso e' cosi' che saltan fuori i problemi di performances.
Per queste ragioni il mio consiglio e' leggermente diverso da quello di StM, che rettificherei in: "tutto sta ad avere un progetto da curare in cui puoi applicare e sviscerare immediatamente le conoscenze apprese, secondo me. Possibilmente ambizioso e difficile. Magari molto piccolo, ma devi finirlo".
