Learning CS

I had a talk with my friend Jessa at lunch about learning CS.

I have long thought that CS should be one of the easiest engineering fields to enter. Granted, it is not completely trivial, but I think the barrier to entry is relatively low. Modulo the one time cost of owning a computer and setting up development environments, the cost of starting a new “experiment” or measurement is trivial. Unlike other engineering disciplines, you do not need a physical test bed. You do not need to do any mechanical work or wiring.

Resources are an issue; however, it is not as expensive and are in an abundant supply for the common case. The cost of “wasting” resources is no where near as bad as say, mechanical engineering. Even better, our resources have been governed by Moore’s law, thanks to EE! (Well, not so much with memory).

In other disciplines, the entry barriers are dealing with problems with reliability, efficiency, and managing resources. CS, at least in the beginning, does not seem to be concerned with these issues.

So, where is the difficulty in learning CS?

One clear difficulty of CS is the fact that it stems from mathematics. Other engineering fields build upon different fields of science. With science, the laws are governed by the real world, in which we can develop a strong intuition. On the other hand, math in its purest form is completely abstract.

However, in teaching CS, I have found that this is not the common case. In my view, most people with even the slightest mathematical background know how they want to solve a problem. Our brains are very adept at pattern matching and so, when we are faced with a problem, we usually know (maybe subconsciously) what steps we need to take. The primary problem is that the steps are jumbled. Our brains do not act linearly like a CPU would. Thus, I see the most of the work as translating these jumbled steps into a linear sequence. Its a permutation problem. If you have steps, then there are a total of permutations. Although (or using sterling’s approximation). Yes, this process may be slow, but it is finite. Finiteness, even if large, is a good thing compared to other fields, such as math, where solutions are an infinite distance away.

Good coders understand these permutations better than bad coders. They have a better heuristic when searching through the permutations. They have seen similar problems and remember how they sequenced those. They may know that certain steps have to be in certain places, there by changing the problem from sequencing steps, to just sequencing , for some constant .

Yet, this is not all that is at play, and that key missing element is abstraction. Good programmers (and scientists and smart people in general) understand abstraction. In programming, it is no longer just sequencing, but also grouping. Whereas having a good search heuristic can avoid branching off in bad directions, abstraction allows one to shrink the search space drastically. Effectively, this is the idea of “divide and conquer”.

Almost all programmers have seen abstraction at work. Libraries simplify problems greatly by providing such abstractions for us. It stops us from having to re-invent the wheel. Design patterns help us tackle particular problems in a consistent way. Most programmers know how to “use” abstraction; however, great ones know how to create new abstractions. While they may not be good at sequencing, good abstraction divides problems into shorter groups of sequences.

In words, the product of the number of permutations of the groups, is less then the total permutations of the whole. Here is where we see the most drastic speedup. We get orders of magnitude difference because instead of replacing with , we get .

Again, all of this hinges on the fact that someone can even begin solving a problem and this clearly divides the population of students in CS classes. For some, problems seem infinitely far away (as math is to me). For others, they understand the steps; however, cannot or will not express it correctly. I feel that we should be teaching these two not necessarily disjoint groups of people separately.