Computing Smarts

Suppose you're interested in starting a software company. You're interested in finding the best and brightest. But, really, what is the best and brightest? You might be able to measure such a thing once the person is hired and you assign tasks and they get it done faster than you expected with higher quality than expected.

But what's one level lower than this?

To illustrate, I'm going to jump over to another domain. Teaching computer science. I've blogged before about how the goals of teachers of computer science are often at odds with those seeking to hire the best programmers. Let's face it. Programming ain't easy. In fact, it's quite hard, at a number of levels.

You have to know nitpicky details of the semantics of a language. For example, why can you assign an array written as {1, 2, 3} only when you're declaring the variable, but not in an assignment statement? There's reason in C not to do this, but far less reason in Java. You have to remember that most comparisons do not return -1, 0, 1 but return negative, zero, or positive. There are a myriad of such details that seem to have little to do with understanding programming.

Then, you have to understand how to use the language properly. How to find the min or max of an array. How to use recursion. And so forth.

Then, if you're doing OO stuff, you have to work one level above that. Which classes should I use? How should they interact with one another? How should I test them? And so forth.

Then, you might have to go one level above that, the level of a software architect. How do I decide which enterprise solution to use? Which language to use? Which form of network communication? Which database? Which persistence engine? And so forth.

Most programming classes never really hit the last two levels, but that goes to show you how much there is to think about to be good. What do you think most teachers would prefer to test? They want to know if you can write code to do something. They don't care that much about syntax, or whether you remember the methods to this class or that class. In principle, you can look it up.

Ah, now that's the catch. You can look it up.

So, here's where I make a distinction. There are some people who if told everything they need to know (which is saying a lot) can get things done. In other words, their ability to look things up is severely hampered. Would you consider this intelligence? How to look things up?

Suppose you're at a company where software engineers don't do a good job of documenting what they do. That's probably nearly everywhere. How many companies have software people writing documentation half the time. And, having the documentation scrutinized as closely as editors scrutinize writing for books that get published? That would save some time for people later on to have this documentation, except that, code changes fast, so the associated documentation has to change as fast. Can documentation be tagged to a particular build?

So you lack documentation. Now, you have to sit and sift through code, which is similarly lacking in documentation, and try to surmise what the heck is going on. Maybe, if the coder is doing something sensible, they are following well-known practices. I recognize this pattern or that pattern. Maybe they are using a library. Gotta go over and check how this library works. What's a Java Bean? What's a servelet? What's this logging mechanism?

But what if you could have an expert who knows all this code, boil down what's important and what's not important. They explain that some of the code is currently cruft and isn't used. They refer you to some websites explaining beans, or better yet, begin to tell you the history behind it, and provide you some examples. You go, yeah, yeah, I'm starting to get it.

Is the ability to find and understand this information considered intelligence? If you could have someone explain the landscape to you, and then you could progress with that information to achieve what you needed, would that make you dumb? It seems like it shouldn't and yet it's quite possibly the defining characteristic to separate those who know and those who don't.

To be fair, real learning is all about locating information and distilling what's important. But there's so much crap when it comes to finding information when it comes to computing. If you're a mathematician or a physicist, you could be pointed to, say, 100 books, and some journals, and if you could follow what was said in all of that, you'd be in good shape.

There's so much technology being generated out there, that even with a good search engine, and the ability to form queries, you still might struggle to find the information you want. For example, suppose I wanted to build a website for an online store. I want a database. What should I pick? Is there a website I can go to that would give me good answers? On the other hand, if I wanted to learn about quantum mechanics, there's perhaps a few good books I could go to, and study them. The good information is much easier to locate.

There's a broad set of skills you need to be considered good at computing, and one of them is knowing how to find information, knowing which skills you need to get good at, and knowing how to get good at them. It feels very much like a wild good chase. There's a sense that we could solve deeper mysteries if we weren't having to chase information like this.

My thinking is that, in the long run, we need to find a much better way to do documentation, and to somehow version that with the software. But most people consider this part of development process as useless, even as it may save time in the long run, and make people more productive.

Ah productivity. Is it overrated? A topic for a later blog.