A divagar un poco.
La mejor manera de aprender a programar es... Programando.
Y luego dejar en barbecho eso que has programado, hasta olvidarte de ello, y retomarlo más tarde.
Con toda seguridad te parecerá un truño imposible de entender y modificar; la mala leche que ello genera (si bien especialmente cuando tu salario depende ello) supone un aprendizaje emocional fundamental.
Programar bien no va tanto de saber la sintaxis de tal o cual lenguaje (eso es el "cómo", y a menudo termina siendo cómo implementar una manola mental innecesaria), sino de tomar decisiones sabias acerca de los muchos "qué":
¿Qué sub-problemas componen el problema que debo resolver?
¿Qué es más importante, que sea mantenible o eficiente?
¿Qué estructuras de datos harían la vida más fácil al siguiente pringado en leer este código?
¿Qué librerías ya implementan parte de lo que tengo que hacer?
¿Qué consecuencias tendrá si el usuario ejecuta X tareas o mete X datos, siendo X algo que nadie ha contemplado?
¿Qué es mejor, modificar tal o cual módulo o reescribirlo de cero? (respuesta buena por defecto: reescribir)
Y un largo etc.
El mayor error que suelen cometer los programadores novatos es programar antes de pensar.
Y es fácil: google -> cómo ejecutar un forlayo -> copiar & pegar. Pero igual lo suyo era implementar filostros, no forlayos.
He currado con programadores indios, y el 80% caía en eso: copiar & pegar sin entender nada. Y repito, no se trata tanto de entender el cómo, sino los qué's.
Pero puestos a recomendar un libro sobre programación:
Memorias de un ingeniero eBook: de Hoces, Alfredo: Amazon.es: Tienda Kindle 
que alguien guíe a esta pobre alma perdida por favor.... Esto me recuerda cuando una vez, hace años nos trajeron a la empresa a una señora de unos 60 años a hacer prácticas de Mysql 
