I recently attended training for Cognos Metadata Modeling. This experience highlighted for me one of the key difficulties in becoming a top-notch IT professional. Maybe it is a result of the IT profession still being a relatively new industry, or the demands of students, or something else, but training and documentation tend to almost exclusively address the how of performing a task, without explaining the why.

For example, the Cognos training manuals showed us how, step-by-step, mouse click-by-keystroke, to go through the motions of transforming the source data into a usable data model, suitable for report creators and other data consumers. What the manual did not spend much time on at all was why we were making the decisions that we were making in the first place. Luckily, the instructor (Brian) did a top flight job explaining this as we went along, as well as answering all questions about that aspect of the material. The fact remains, if it were not for Brian, I would not have learned anything that F1 could not have taught me. In short, the curriculum as formally laid out was a five day course in how to click, copy/paste, and drag/drop.

This training course was not an isolated incident. During my brief stint as a Computer Science major (regular readers may remember that I double majored in “can’t-get-a-job-ology”), the courses were extremely concentrated upon theory, the why of what programmers do. The coursework at my college was extremely why oriented. The vast majority of the students were constantly complaining about this. They wanted to be taught how to program in a particular language. Indeed, it was assumed that you knew the language used for the class, and it was up to the student to learn it on their own. For example, CS 111: Introduction to Programming used Pascal to teach the basics such as variables, loops, control structures, and so on. The next course (CS 112: Data Structures) used C, with no explanation of the C language. I had the good fortune of looking at the syllabus in advance and learning C over my summer vacation. The bulk of the students did not do this, and were tripping over C, which was merely being used as a tool to teach data structures.

In retrospect, I wish that I had stuck with the Computer Science program there on some levels. It was the only time that I was offered a chance to really learn Computer Science as a science, as opposed to a vocation. That is the difference between a why oriented education and a how oriented education. Learning the why means that you understand the underlying theories and principles, without necessarily being taught the implementation end of the process. The how based education teaches you to implement something, but you really do not learn how to make the architectural decisions that you need to craft quality code.

Unfortunately, as my college experience showed, this is exactly what students want. Schools such as DeVry and Chubb (I have talked to a number of graduates from their programs, and inspected the coursework and books) are how oriented. They teach students to lay bricks, but not to design the building. The Cognos training was the same way. We were being taught how to have the software do what we wanted it to do, but not how to know what we needed it to do. The end result? “Shake and bake” programmers.

There is nothing necessarily wrong with “shake and bake” programmers; someone needs to do the grunt work. But at the end of the day, it is the grunt work which often has the biggest impact on end user satisfaction. If the person writing the code that parses the data file has a poor understanding of things such as the impact of various file reading techniques on performance, the program will run slowly. If the person designing the interface has no knowledge of usability theory, the application will be difficult to use. The programmer ignorant of proper optimization of SQL statements is going to be writing code that makes the server beg for mercy. And so it goes.

Language documentation is frequently not much better. It serves as a syntax reference, and not much else. Rarely does the documentation for a language offer any suggestions or tips as to where, when, and why you would choose to use one technique as opposed to something else. The Perl documentation is the only significant exception to this that I am aware of. As a result, people using the documentation as their reference rarely learn that there may be a better or easier way of accomplishing a task. For example, a programmer coming from a language without a built-in, optimized file slurper object may simply try to rewrite their standard file slurping code in the new language, without knowing that there is an easier, more optimized method available to them. This is where the Perl documentation shines; the FAQ’s are complete why oriented. They are laid out like, “I am trying to accomplish XYZ, what is the best way of doing it?” The answers show not just the best code, but often have different variations with an explanation of which one is best in which situations, and why. More language references need this kind of documentation, as opposed to the current system which is more or less a syntax reference and an explanation of what each parameter is and what the output is.

Over the years, I have held onto my passion for programming. As a result, I am always reading things that are at least indirectly tied to software theory. Even when I am reading something that I do not think is related to computers, I start to wonder how the can be applied to software design and development. I spend time experimenting with languages that are not popular, to see how the methods they use can be applied to my job, and evaluate the suitability for use in projects. And so forth. The why of software is what interests me, not the how.

A properly designed architectural document for a program is the essential blueprint for implementing a software project. Without a good understanding of the why of code, it is very difficult to construct the best possible how. This is why I think that a major shift has to occur in the attitude towards training and documentation.

J.Ja