I am sure that the quality of IT teaching is now much improved from the days when I used to fall asleep to the dull drone of a technician who was patently out of his depth. Fortunately for me (and everyone else in my class at college) I had already taught myself BASIC and was sufficiently good at maths to understand enough about the flow of data and logical progression through a program to ace the topic and was happy to use the other half of my time teaching the class during our tutorials.
Moving on to a job as a COBOL programmer I quickly found myself with two interesting skills... firstly the forethought to control the flow of a program in such a way that most 'problems' simply could not exist (specifically the rigid control of inputted data and the writing of numerous distinct, robust and simple modules). Secondly, I had an unnerving knack of being able to identify the weaknesses in programs and was always in demand by the other trainee programmers to "find coding error that crashed their batch run" and to "test to destruction" their own creations.
Ah, the good 'ole days when a "finished product" was compiled and then packaged, ready for distribution... not the offensive torrent of 'beta' releases that never actually get fixed or spend their entire (and short life) being updated, fixed, patched... Rule 1 has got to be, "the project may be complex - but keep the modules simple".
In all my time as a programmer and subsequently in helping others to attain similar qualifications and indeed whilst later teaching myself dBase(III and III+) I have discovered that the single most common problem in IT is sheer bloody incompetence, the source of most errors is inherent habitual laziness, the most common program writing error is a "," instead of a "." and the number one error is not in programming, it is a lack of rigorous testing.