Home Company Profile What's new? More about me Related sites Books Courses ? Why a flounder? Downloads
	A Degree in Brick Science
	A number of us out here in the Real World have been appalled at the quality, if such a word can even be applied, of bright young undergraduate Computer Science students. In my teaching, I find people who are essentially functionally illiterate in their profession. What should a graduate be expected to know? Certainly, how to create and manipulate a linked list, how to set and clear bits in a value. They should know the syntax of whatever languages they claim to be proficient in. I teach courses in which "knowledge of the C language" is a prerequisite. In some cases, I fully believe the prospective students interpret this "Can spell the name of the language, with only an occasional error".  A student was stuck on a problem in writing a piece of code. I said, "well, in that case you would have to write something of the form 'if condition then ...' and only do the computation if the condition holds". This seemed obvious. A few minutes later I looked over his shoulder, and he had typed, in a C program if condition then and was trying to decide what to write next!

void AddToList(Item * p)
   {
    if(head == NULL)
      head = tail = p;
    else
      {
       tail->next = p;
       tail = p;
      }
    }

One student had serious problems with this. It wouldn't compile. This is because I had pre-supplied them with a prototype function

void AddToList(Item * data)
   {
    //... your code here
   }

Of course, you can probably guess what happened: he copied the text directly from my example, and couldn't figure out why the symbol p was undefined. 

By far the worst was a woman who worked at the Software Engineering Institute. She was a brand-new hire from CMU, one of the top-rated computer science schools in the country, or perhaps the world. She had written

printf("The value is %d," value);

and the compiler was giving her a syntax error. I spotted it (can you? Go take a look...) in seconds.

So I said to her, "you transposed the comma and quote mark" and walked away. A few minutes later as I passed back she told me it still wouldn't compile. So I saw the same error, and said "You have to put the comma outside the quote mark". She looked at me, and in perfect sincerity said "But the comma always goes inside the quote mark!". I started to explain to her that no, it was a parameter separator and had to go outside the quote mark, and she interrupted me to insist the code was syntactically correct. Everyone knows the comma belongs inside the quote mark! Why, her English teachers had downgraded her text when she put the comma outside the quote mark!

I made some remark about she was clearly too stupid to know how to breathe, and I was certainly not going to waste my time explaining C syntax to a CMU B.S. in Computer Science. I did my best to get her removed from any place that might put her in actual contact with a computer, but there was no one with the taste or intelligence to get rid of her. But I managed to avoid her the remainder of my time there. She once wrote a program we were all supposed to use; it was so bad it would have been an embarrassment to my nephew when he was12; he had been programming two years at that point (he graduated in 2003 with a degree in computer graphics).

Peter Viscarola, in his "Peter Pontificates" column in the OSR newsletter, has similar observations. He talks about interviewing prospective candidates who had two semesters of Operating Systems and couldn't explain synchronization. Who had two semesters of Operating Systems and had not written a single line of code during that time. I know someone at Microsoft whose test to prospective new hires was "Insert this item into a linked list in sorted order". Of the 27 prospects, exactly one, a woman working on her PhD, was able to do it at all.

I have at least some idea of what is going wrong. 

The Brick Science Major

Imagine that there was a Brick Science major in a university. What would it look like, if it were modeled after most Computer Science programs? 

In the freshman year, we teach the students about bricks. The kinds of bricks. The sizes of bricks. The purposes of bricks. Plain bricks, glazed bricks, outdoor bricks, paving bricks, fire bricks. Each exam tests their knowledge of specific kinds of bricks and what they are used for. 

In the sophomore year we introduce them to Brick Theory. How bricks are made. What goes into the mix. The effects of impurities in bricks, both negative (defective bricks) and positive (coloration). We teach them the chemistry of bricks. The proper firing temperatures for different kinds of bricks. They learn how to analyze brick performance (breaking strength, water permeability, robustness and other considerations in Analysis of Bricks). They finally understand why some bricks come with three little holes in them (they knew about the existence of these in their freshman year, but not why they are present). 

In the junior year we explain about how mortar puts bricks together. Since they now have more background, in two semesters we start with basic mortar theory and work down to optimum blends of mortar for various purposes. They learn about curing time. They learn about brick-mortar combinations. They learn about pointing, and why it is necessary. They know how to determine the bonding strength by measuring the forces that are required to split two bricks that have been mortared together. 

In the senior year we introduce them to systems. We talk about the costs of field deployment of brick-mortar systems, including installation and maintenance, long-term issues such as system robustness under weather, salt, and other stress conditions. And we have a senior project. Each group of students gets to build a three-block-high, six-block-wide wall, using bricks and mortar of their choice, and explain why they made these choices. 

They graduate. They have a B.S. in Brick Science. 

Their first assignment: "Build a decorative brick wall". 

At this point they realize, or should realize, how little they have actually learned. They have never built anything larger than 18 bricks. They don't know that trick all bricklayers use, of stretching a cord so all the bricks are level along the 100' wall. They certainly wouldn't have any idea about the modern approach, which is a laser that "paints" a line across the bricks. They don't know how to deal with wind forces on a tall wall. Nobody told them about footers or frost lines. They don't even know how to use one of those bricklaying hammers to split a brick in two. And they haven't the foggiest idea about aesthetics, so they don't know what "decorative" really means. 

In the building trades, there is training, but this is just a preparation for "apprenticeship". That lasts several years, under the tutelage of experienced bricklayers. Only after a certain skill set is demonstrated is the individual promoted from "apprentice" to "journeyman" (or to be politically correct, "journeyperson"). When a level of serious expertise is achieved, the person becomes a "master". All too often, junior programmers are treated as if they are experienced, and are abandoned. I've spent a lot of time mentoring junior people, and it is an absolutely necessary part of one's professional responsibility. But before they are worth mentoring, they have to be functionally literate. With a few notable exceptions (such as the SEI hire) these are not learning-challenged people; these are people with Bachelor's degrees from often major universities. If they don't know the basics of their profession, it is either their fault, or the fault of the programs they go through. A bricklayer is expected to be physically capable of doing the work, and able to perform tasks such as adding and subtracting, using a ruler, and knowing which end of the trowel you hold and which end you dip in the mortar. That SEI new hire was, relative to her claimed profession, incapable of recognizing a brick. Everything else was more sophisticated than that.

When I told this story to a friend of mine, Kevin Nolish, a senior engineer at Marconi, he said "No, the one difference between your story and reality is that it is more likely the foreman puts his arm around the new hire's shoulder, points him to a pile of lumber, and says "Go forth and build"."

What about other schools who have a more "application-oriented" curriculum. It is simple. The program works like this:

In their freshman year, they are told about paving bricks. An entire year is devoted to how to use paving bricks.

In their sophomore year, they learn how to make entrance porches out of paving bricks.

In their junior year, they learn how to make sidewalks out of paving bricks.

In their senior year, they learn how to make driveways out of paving bricks. This is very complex, because they have to deal with supporting a heavy weight.

The post-graduation scenario is the same.

This is like the schools that offer a "computer science" major in which all the programming for four years is done in exactly one of Pascal, C, FORTRAN, BASIC, Visual Basic, Java, COBOL, or whatever (the language changes with the current language fad; the problems remain). If you ask the students what a "finite state machine" is, they look at you blankly. Tell them their algorithm is n² and they glaze over. They would not recognize an NP-hard problem or a unsolvable problem if one came up and bit them on the ankles. They have probably never done a team project, or written a program larger than 1000 lines. Perhaps not that large.

The self-taught bricklayers go down to the local home improvement center, buy a sack or two of some kind of mortar, a trunkload or two of some kind of brick they find on sale, and go home and build the wall.

The good ones buy a good "how-to" book about bricklaying. Most of them read it. Some of those try to understand it. A couple of them actually do.

None of these people, in any of the above scenarios, are actually exposed to a professional bricklayer.

When the wall collapses, or buckles, in the first Spring after it is constructed, people like me are called in to rebuild it.

Sometimes people complain when I am acerbic about semi-random piles of bricks more-or-less held together by something approximating mortar.

True story: we once had an interviewee for a job who seemed a little below threshold. My associate asked him "What is the largest program you've ever written?" He proudly said "800 lines!" The previous weekend I had written 2500 lines of code. That included several hours off to go to a symphony performance. I am in the habit of referring to "trivial 10,000 line programs" which has a tendency to shock whatever students I'm talking to. Most of them think of a 5,000 line program as a massive work. Most of my serious programs run around 100,000 lines; some are up to about 250,000. I once wrote 100,000 lines of code in one year. My coworker, who was also running the business end of the company, only wrote 70,000. The program had been almost 80,000 lines in February, when I was hired. It was 238,000 at the start of March the following year (the numbers don't quite sum up because we also threw some modules away. He worked in a nearly-totally-disjoint set of modules from the set I worked in, so we could easily account for who-wrote-what). He was a completely self-taught programmer who wrote some of the most elegant code I had ever seen. He was an artisan who programmed (he actually was an artisan, having done a lot of fancy woodworking before he went back to school to major in CS). 

[In the 5 days preceding my writing this essay, I've written 4470 lines of source code. My billable time was 31 hours. That's 144 lines/hour (Japanese Programming Productivity Standard), not including the 28-page reference manual to go with it which I wrote during the same period on the same billing time. The Japanese Productivity Standard allows me to count the lines of existing libraries I can reuse. If I deduct the 1038 lines of existing library I used, that's 3,423 lines, or 110 lines/hour of real productivity. This is slower than my usual standard because this had to be utterly beautiful "reference code", had to be compilable on at least three different platforms (NDA forbids me from saying what the other two are) and I sweated over it, and we did at least one nontrivial revision that involved throwing away a few hundred lines to simply the task, once we had the correct model. At one time, the industry productivity standard was 5 lines per hour, with a "super-programmer" able to write 20 lines/hour of deliverable code. And that was without full testing and documentation.]

I've worked on projects involving 20-30 programmers, producing production code which had to be used by many other people. Concepts such as unit testing, checkout/checkin, build integrity, etc. are critical here.

It is the responsibility of the senior people to train the junior people. It is the responsibility of the universities and colleges to prepare them for that training. This means teaching them how to reason about programs, and how to learn. Everything else is just syntax.

Give me a programmer who knows how to reason about programs, and I can teach him/her the syntax of the language in a short time. I don't have to explain why a construct makes sense, only how to implement it in the language/environment of choice. And I can explain how to maintain modularity, abstraction, and build well-structured programs without having to explain why it is a good idea. The hardest problem is teaching people how to reason about programming as an art form.

Recently, I was asked to comment on a piece of Windows code. It has to rank as among the most incompetently-written pieces of code I had ever seen. It would not make sense in any language, on any platform, in any environment. My comment was that I had stopped reading it after four lines, because it was clear in those four lines that the code was unsalvageable. Nothing else would matter. It was followed a few days later by an even worse example from the same programmer. The poster asked how he could convince his manager the author of this code was just taking up space. I commented that it was worse than that. Someone who is just taking up space has no net productivity. This person was incredibly dangerous because he was not just taking up space; he was actively causing serious damage. A person so incompetent that the only possible service to society was to keep him as far as possible from any compiler. "How could code this bad pass a code review?" I asked. And then said "You do have code reviews, don't you?", knowing perfectly well the answer was "No". No sane organization could have passed code like this. The deficiencies of this programmer would have been made obvious, nearly instantly. It would be clear that the only solutions were either to get this person trained, or get rid of him. 

Code reviews are important. There is no code that cannot be improved by a code review. I especially include my own code. I've had to do code reviews for clients, as I train their programmers to take it over. I find bugs. I find poorly-coded algorithms. My code always improves as a consequence of a code review, and it is really good code to start. The improvements are usually minor changes, but they are nonetheless improvements. And the programmers I'm training always learn something new and useful.  

No construction foreman in his right mind would charge a brand-new Brick Science major with the task of building a decorative brick wall without making sure the person was properly trained, and would carefully supervise the person. And would probably not be polite about really stupid design decisions ("What do you mean, 'What's a footer?' Where in the $%#! did you learn how to build a wall?") Yet programming managers regularly assume that their new Computer Science majors are competent to program. I have found this is rarely true. Most of them are almost literate; some of them can program a linked list without their lips moving (I'm not kidding: see my earlier comment about a roomful of CS majors, none of whom knew how to build a linked list). Some of the code I've seen in production would not survive a code review. Imagine if a building could be built without any form of building inspection to certify that it was safe. I've had to go down to the courthouse and apply for a building permit to do home improvements. I had to provide plans. I'm experienced enough to know that I have no idea how to build a deck, or reinforce a building, but I know how to hire people who do. If I were going to make my career as an architect, I'd sure find the best people to learn from. 

[True story: one day I went down to buy a building permit. The person ahead of me in line was being heavily grilled by the person behind the counter about things like shear strength of the connection of his deck to his house, load-bearing of the floor of the deck, etc. I kept thinking "I'm doomed. I can't answer any of that!" My turn came. I presented my plans. The person behind the counter picked up my plans, looked at the embossed "Registered Professional Architect" seal down in the lower corner, looked at me and said "That will be $15". That was it. The plans cost me $400. Worth every penny.] 

One reason that I consider myself a good programmer is that I learned from some of the best. And for that matter, some of the worst (as in "I would never build anything that shoddy"). But certainly the good things I learned was from programmers more experienced and tasteful than I was (especially in my 20s). By the time I was in my 30s, I was good, and I've been trying to become better all the time. I read a lot of code. I see a lot of good ideas. I try to make them my own.

The views expressed in these essays are those of the author, and in no way represent, nor are they endorsed by, Microsoft.

Send mail to newcomer@flounder.com with questions or comments about this web site.
Copyright © 2003 The Joseph M. Newcomer Co. All Rights Reserved.
Last modified: June 20, 2003