Wednesday, May 9, 2007

What We Do

"I'm programming in the Bay Area," I usually reply. This superficial answer is unfortunately about as deep as non-tech people want to hear. Computer science has the dubious distinction of being the most popular profession that most people don't understand. It's certainly not helped by a media image of a loan hacker sitting in front of a glowing screen in a dark room. I'm going to try to boil it down so that my mom and sister can understand the basic areas of the computer profession. I try to avoid metaphors because I want people to understand what I *do* do, not what I "like" do.


OK, maybe not the best group to start with, since this group includes the load hacker in the dark room. But more commonly, these are the folks that write detailed instructions which tell the computer how to handle specific situations. For example, at Amazon, when you search for products, the words you type in the box have certain rules applied to them. When you type "shirts" products labeled with "shirt" need to come up, so you need a rule to singularize the words. But think about the English language: this isn't easy. Boxes, hoodies, shoes. So a coder needs to come up with instructions to handle all of these cases, the rule to "remove the last 's' from words that end in s" will only be a part of it.


Computer engineers take real world problems, break them down into smaller sub-problems, and describe a general way to solve them. Coders take that general solution and write specific instructions to the computer to solve the sub-problem. Continuing the search example, engineers took a problem -- how can people find products they're looking for? -- and broke it into sub-problems: if people tell us what they're looking for, how can we give them suggestions? if we have a list of suggestions, how can we show them? Then they arrive at a general solution: people type in a short description of the desired product to tell us, we make a list of products that have all of the words they're looking for in their description, then we show some of the products on the web page.


This is my group. 'Ops' is in charge of keeping the software running. Sometimes programs crash; we develop software called 'cradles' which can restart a program in the event of a failure. Sometimes programs get overloaded when everyone logs in at once to begin their Christmas shopping; we set up new computers and faster networks to handle increased number of users. Sometimes software mysteriously starts running slower than usual; we discover assumptions that coders or engineers made that aren't valid and try to work around them. One example is if a machine runs out of disk space. We either produce software that detects this and removes old files, or do it manually.

Quality Assurance

QA teams develop and run tests against the software. They make sure that a search for 'shoes' matches products with 'shoe,' not 'sho.' Many techniques are involved in this: regression (comparing a new version of the software to the old), unit test (compare each part of the software, for example just feeding words into the part of the software the singularizes), corner cases (what happens in weird situations like using foreign languages).


Computer scientists usually write two types of research: papers which solve hypothetical problems, or papers which analyze a class of solutions. The hope is that hypothetical problems will eventually become real problems for the former, or that by analyzing a class of solutions, an improved solution to an existing problem will make itself apparent. For the class I am taking, an example of the former is papers from the 1980s which try to solve how computers should keep in sync with each other: when I transfer money to your bank account, that money shouldn't disappear, it should either be in my account or yours. However, the techniques that were proposed at that time aren't working so well, so more recent papers are analyzing the techniques that engineers ended up implementing.

Now You Understand Completely

Well, not really. It turns out that most jobs are a combination on these fields. Engineers often code the specific instructions after they describe the general solution. QA folks have to understand what real world problems a program is trying to solve in order to think of test cases. Scientists work with companies to develop solutions for specific problems.

Additionally, this is just a taxonomy I wrote down after a little thought. Certainly there can be other ways to organize the field, and you won't get a definitive answer if you ask people "what category are you in?" Hopefully, though, this can give you a background for some of the issues that are discussed around the computer industry.


Coding jobs are the main target of outsourcing. Because the process of coding is often closed -- general solution in, computer instructions out -- coding teams can be separated from the end customer.


Universities want to produce engineers, but often they produce a mix of the worst qualities of scientists and coders. They produce a scientist's attention to implementation details and a coder's attention to the overall problem being solved. Classroom projects are run in an academic setting and don't need to worry about security, portability, or decade long maintenance issues. Without a bigger picture, coders can product instructions that are technically correct, but which fail to anticipate customer needs and implicit requirements.

"Why aren't you programming?"

Graduate classes in computer science focus on the science aspect, not coding. That's why my assignments don't involve programming and why professors often need help setting up their Windows computer. When programming is involved, it is used to assess how well you understand a problem. If you can write instructions to the computer for every situation in a problem space, then you've demonstrated good comprehension of the problem and solution.

The Story Continues?

Agree, disagree? Write comments :)


Khanh said...

goood stuff blomo... well articulated.

mom said...

...and your mother appreciates the clarification...but would you please put another "s" on "asses" in the last paragraph...thanks!