Diversity hiding in plain view, or my thoughts from a SXSW 2013 panel

Conversations about diversity in technology are as interesting for who they include as who they leave out. Their goal should be to challenge the stereotype of a programmer as a young white male, unencumbered with anything that would keep him from coding 18 hours a day. The panelists who got together to discuss diversity in the Austin tech community were not in this category. But diversity is more than just being female or a person of color.

Those categories are, however, the most visible, and no wonder that the conversation revolved around them. There are companies who have been setting examples in how to bring under-represented groups into engineering. One of them is Etsy, the online craft marketplace, where one of the panelists, Garann Means, worked as a software engineer. Etsy noticed that while most of its customers were women, most of its engineers were men, and they set out to change that. Instead of poaching women developers from other companies, they started the Hacker School, and gave scholarships for women learning programming. Many of its women graduates found software engineering jobs. Moderator Mark Phillip noted that when Etsy committed to diversity, it also benefited male developers -- they became better team players.

Mark Phillip (CEO/Founder Are You Watching This?!), Nicole Cofield (president/CEO of Capital City African American Chamber), Garann Means (software developer), and Gerardo Treviño (founder and CEO of Paybook). More pictures from SXSW 2013 are in my photo gallery.

Garann (who is also the founder of All Girl Hack Night, Austin women developers' group) says that diversity efforts are often criticized as "we shouldn't separate women from men, we want to keep them in the same group". But she says that this kind of separation is never an issue, at least in her own experience. Many white guys talked to her about how things that are "supposed" to offend women and people of color, actually offend them as well. It is sometimes said that a special effort to attract more people from underrepresented groups to software industry would bring a lot of underqualified people. But there are examples showing that that doesn't have to happen. Garannn says her friend Divya put together a conference in San Franscisco, with very diverse speakers, and it was technically excellent -- you didn't have to sacrifice the quality.

People categorize themselves in interesting ways that can be different from the categories we assign them to. I saw this play out in my own life as well, and I was reminded of it by what Natalie Cofield, president/CEO of Capital City African American Chamber, said. Many black engineers in tech are not Americans: they come from African countries. She has heard Nigerian programmers say "African American Chamber is not for me, because I'm not African-American. I'm Nigerian." So she saw a need for AAC to be more internationally inclusive. I can relate to this from my own experience. As an international graduate student in America, I felt I was more of a minority here than the officially recognized minorities. They were at home with this country's ways, and I was not. (I know it's a subjective feeling, and a white foreigner still benefits from the white privilege without realizing it, so I would not put my experience on the same footing as that of truly underprivileged minorities.) But when the Natalie Cofield mentioned a need to include foreign-born engineers in the tech community, it was the first time I felt that somebody was inclusive towards immigrants in this country. It was certainly the first time in my experience that somebody wanted to make them a part of the diversity discourse, as opposed to treating them as a job-stealing, wage-depressing nuisance, which is how high-tech immigrants are usually talked about in this country.

Then there is another dimension to diversity, hidden in plain view. It came to my mind when the fourth participant of the panel brought up something, and his story was considered a success story without anyone noticing the darker undertones. Gerardo Treviño was talking about Paybook, his recently launched startup. It lets people take pictures of their receipts, and Paybook will parse them for you. He and most of his developers are from Mexico. At first he wanted to base his company in Austin, but it was very difficult to get USA work visas for the whole development team. Abandoning that plan, they decided that the company's home will be Monterey, Mexico. They wanted a safe place with landscapes that help creativity. So they got the whole team of a dozen developers to live together in Playa de Carmen, an organic food paradise, in a utopian commune of sorts: for example, the whole team collectively decides what to eat for dinner that night.

Mark Phillip (CEO/Founder Are You Watching This?!), Gerardo Treviño (founder and CEO of Paybook), Nicole Cofield (president/CEO of Capital City African American Chamber), and Garann Means (software developer). More pictures from SXSW 2013 are in my photo gallery.

No one in the audience indicated they viewed it as anything but a creative move, and perhaps it was; but such a move would only work for a team of people who have no other responsibilities outside of work. Clearly, someone who has children would hardly be able to leave their family and move somewhere for months at at time. This is especially true about people who have been traditionally responsible for childcare, namely, women. So I wouldn't say that it's really diversity when you pick employees who are free of family obligations. And since they tend to be in their 20s, you are clearly not aiming for age diversity either.

This goes against bringing more women into computing, because women would be the first to quit a company, or entire industry, that makes it hard to combine a job with a family. Even child-free women are less likely to stay in such a company, because they still want to have friends and personal lives. Encouraging your employees to relax on a beach or eat organic food is not a true support of work-life balance; the balance needs to be the kind that lets people fulfill their other responsibilities.

It reminds me of a story I read in our local newspaper, Austin American-Statesman, about tech startups that open offices downtown. They want to be in an attractive location, because their engineers like to to live music clubs or to the lake after work. Clearly, they are trying to attract only a certain kind of engineers, namely, those whose after-work hours are spent on leisure. They are not positioning themselves for another kind of employee who goes home to their family in the evening. It just so happens that the first kind is usually in their 20s, while the other kind is older and more likely to be female. So in the era when sex and age discrimination is illegal, this is a roundabout way to tell the non-20-something-male applicants that they are not particularly wanted here. And I think that as long as companies have implicit preferences for certain kinds of demographics -- expressed by supporting some lifestyles but not others -- I think that all the talk about bringing more diversity into tech won't yield much fruit.

SXSW 2013: blending bendy materials and bendy life

A talk by Ping Fu at SXSW 2013 blended, in an odd way, self-help advice and 3D-printing technology. The only thing in common between the two may be her own personality, which, like those raw materials shaped into an infinite collection of shapes, succeeded by flexibility and adaptability.

The title of her speech, "Digital Reality: Life in Two Worlds" ostensibly refers to the merge of physical and digital reality. She reviewed exciting things happening in three-dimensional scanning and printing technologies -- and her company, Geomagic, is among the players in the field. Standing on the stage in 3D-printed platform wedge shoes, she said you may be able to walk into a Nike store tomorrow, have their feet scanned, and pick up custom-made shoes tomorrow. You may also have custom-made prosthetics that would let artificial limbs look like real ones, "because currently they look like airplane landing gear". You just have to scan a soccer player's "good" leg, and print an artificial one based on that model. 3D-printing can produce filling for dental cavities, and repair tiles on NASA space shuttle -- two technologies that surprisingly (or not), are related. Preservation of historical artifacts is also a big application for 3D-scanning. Mount Rushmore took a hell of a long time to scan, but it was eventually done, and US Parks and Wildlife has a scan, said Ping Fu.

Ping Fu's 3D-printed shoes she wore at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

On the other hand, life in two worlds can be a metaphor for Ping Fu's own life, that has certainly spanned two vastly different worlds. As a young child she was taken from her loving family in Shanghai during the Cultural Revolution, and raised in a camp. She was put through communist brainwashing, being forced to go up on stage and scream "I am nobody!" So she has no stage fright, she jokes. If anything saved her, it was her father's advice to be like a bamboo, that bends but does not break in the wind. She even made it the title of her book, "Bend, not Break".

A soccer player's 3D-printed prostethic leg. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Looking up this book on amazon.com, I saw that many reviewers accuse her of fabricating her life story. They claim her actual life was not nearly as horrible as described in the book, and that she might not have lived in a labor camp. I have no way to verify the claims of either side, though there is no doubt that the horrors of Chinese labor camps, where middle class children were sent for "re-education", actually existed. There is also no doubt that Ping Fu at some point immigrated into the US, and went from a person who knew just 3 English words, to a tech entrepreneur. And though she chose a technical field, she credits her love of language for her design skills. She may have known little of English, but she had a love of language all her life.

In China, she went to graduate school for journalism around the time when China's one-child policy started. It made not just subsequent-child births, but also pregnancies, illegal. When Ping Fu heard rumors that baby girls were being killed in the countryside, she went there as a journalist to investigate. There she witnessed "abortions" done via C-section in 8th or 9th month of pregnancy. For writing publicly about these atrocities she was put in jail, and was certain she would die there. Luckily, Cultural Revolution soon ended -- this was a few years before the Tiananmen Square -- and Ping Fu was released. (Again, I have no way of verifying how much of it is true.) Then the government gave her a choice: quietly leave the country, or be exiled to a remote corner of China. She chose to go to America, and took a crash course in English on the plane. By the time she landed in San Francisco, en route to the University of New Mexico, she already knew a few English words. Not enough to be accepted into comparative literature program, which was her first choice, but enough for computer science.

Mobile 3D-printer. This guy and another one with a similar printer walked up and down the aisles to let the audience take a look at the printers. They, however, did not demonstrate how it works. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Myself, as someone who had a love for languages all my life, but didn't go into linguistics because I didn't think there were any jobs in it beyond school teacher, felt vindicated. There are not many people (or perhaps we're just not visible) who come into computer science not because of fascination with technology, but because we enjoy teasing out complex logical structures from the code as we do from human languages. And so when Ping Fu said that somebody back in the day suggested to her that she check out this new field, computer science, because it's a "language" that lets you make stuff, I thought that it was the same kind of thing that attracted me to the field of computing. Her life tale of a foreign student turned tech entrepreneur also has a special resonance to me because I, too, initially came to the US to go to graduate school. She, however, did not think she was a good programmer, because she lacked a science background, so she became a designer and project manager. Her secret to working with programmers is to ply them with Coke to keep their juices flowing. It must have worked, because at some point she hired Marc Andreesen, who developed Mosaic, and eventually licensed it to Microsoft to become Internet Explorer.

For a long time she didn't consider becoming entrepreneur, and when she finally started her company, Geomagic, people were still skeptical. Of the first seven employees all but her had PhDs, and 4 of them were mathematicians. People said you can't start a company with a bunch of mathematicians, as math doesn't make money. But Ping Fu replied that she liked to do impossible things, so she did it. A win for language nerds and foreign students everywhere!

Programming interviews: recommendations versus experience

Three years ago, when I was looking for a job after 10 years of working at one company, I really wished there were consultants to help software developers to improve their resumes and prepare for technical interviews. How enormously helpful it would be if someone who was a developer once to guide your preparation! Especially if such a person collected many years' and many companies' worth of technical interview questions.

Such a company now exists, and its founder, former Google engineer Gayle McDowell, visited Austin last year to promote her book "Cracking the Coding Interview". In her presentation, based on the book, she advised software developers what to expect at, and how to prepare for technical interviews. I found myself agreeing with Gayle half of the time, and scratching my head the other half. If my experience did not match her recommendations, the reason may have been that her advice was directed to (a) mostly beginner programmers, and (b) those who want to work at big companies. No wonder her presentation was paired with a hiring pitch by Amazon Web Services.

Let us see, then, how my experience of interviewing for software development jobs stacks up to Gayle McDowell's advice.

What happens when "they" pull your resume out of a giant pile Gayle's version Pull resume out of giant stack; Spot-check: company names, positions, projects, schools; Skim bullets to see if you've written real code. My experience I haven't been on the recruiting side of things, but I was hoping that that's how it is -- that a real hiring manager (i.e. someone who knows what to look for in a developer), would look for that, as opposed to for buzzwords from an HR bingo.

Resume length Gayle's recommendation: Your resume should be 1 page only, unless you have more than 10 years of experience. In a 2-page resume, no one will read all the points; they might read 50% at most. The hiring manager will skim your resume and notice only some random job experience points. Some of them won't be your strongest. Wouldn't you want a hiring manager to notice only your strongest experience? If so, cull them and put them on a 1-page resume. My experience: I had many seasoned recruiters tell me that my resume needs to be 2 pages. But then, I have more than 10 years of work experience.

Technical questions Gayle McDowell recomended her company's website, CareerCup.com, for a good list of real interview questions. I checked it and the questions are really good -- they don't test your knowledge of a programming language syntax, but rather test your ability to design, as well as deep understanding of object-orienting programming.

"Don't memorize!" Gayle's recommendation: If an interviewer asked you a question you've already heard before in a different interview, don't just spit it out the answer -- tell them first that you've heard it. It's likely that the interviewer will still ask you to answer the question / solve the problem, but you won't come across as dishonest. Plus, they don't want just to hear you spit out the answer -- they want to know your thought process. Seeing that you've memorized some answer tells them nothing about you -- the question was wasted. It didn't give them any extra information about you. My experience: Perhaps this is reasonable for college students, but if I am an experienced programmer, I might have faced certain types of problems in my programming practice often enough that I know the answer off the top of my head. Such is the question mentioned later in this text, where the answer turns out to be binary search tree. What if at some of my previous jobs I searched for data in large lists? Then I could spit out the answer "BST" before I even heard the end of the question, and it's not because I heard it in another interview, or memorized the answer off of some online preparation site -- it's because I know it from practice.

Push yourself Gayle's advice: When studying a code problem, write the solution from the beginning to end. Don't just stop because you think you understand it. When faced with a whiteboard at an interview, you may discover you don't understand it nearly as well as you thought. Write the code with pen on paper -- it's harder than in an IDE, where intellisense helps you. But you won't have IDE and intellisense on a whiteboard. Using pseudocode is OK temporarily, as long as you tell the interviewer you will fill it out with actual code later, and actually do so. My experience: Agree completely. To make sure you completely understand a problem, you need to write it on a piece on paper from beginning to end. Otherwise it's easy to stumble when solving it on the whiteboard. You are used to the IDE doing so much for you, that when you are faced with a blank sheet of paper, you might start thinking, do you need a keyword "function" to declare a function in C#? Or was that PHP? I use lots of pseudocode when writing code on a piece of paper, and I think if the pseudocode is detailed enough, most interviewers would be fine with that. No one necessarily expects you to remember all the 50+ methods of the generic List<> class when you're coding on the whiteboard.

Data structures Gayle's recommendation: You have to know how to implement, or when to use, the basic data structures: linked lists, stacks, queues, trees, tries, graphs, vectors, heaps, hashtables. Especially hashtables -- they come up often in interviews. My experience: I agree about the importance of hashtables. Many code problems I've been given in interviews required use of a hashtable for best solution. Linked lists were the second most popular data structure -- for example, I was asked to write code to reverse a linked list. There was a time when I was asked to write a program for searching a binary tree. But I was never asked about a stack, queue, trie (whatever that is?), graph, or heap. (As for vectors, they are essentially arrays, and they are used in every coding problem -- you can't write almost any code without it.)

Algorithm Questions Gayle's advice: Study the basics: complex algorithms usually unnecessary. My experience: I agree: I have never been given a problem that required more than a simple algorithm. Well, at one point I was shown the code for merge-sort, and asked what was the complexity of that code (it's O(n log n)), and the interviewer asked me which lines of the code contained the log n part. That was the most complex algorithm I had to deal with at an interview, and even then I didn't have to write code for it, only analyze it.

Decomposing algorithm problems Gayle's advice: To make the problem easier to solve, decompose it in 4 steps: Pattern Matching Simplicity and Generalization Base Case and Build Data Structure Brainstorm My experience: Overall I agree, however, I think we think about decomposition differently.

Example of decomposition Design an algorithm to print subsets of a set: {a, b, c} -> {}, {a}, {b}, {c}, {a, b}, {a, c}, {b, c}, {a, b, c} Gayle's decomposition: You start with empty set: S({}) -> {} Find a solution for a one-element set S({a}) -> {}, {a} For a two-element set, the solution is still obvious: S({a, b}) -> {}, {a}, {b}, {a, b} S({a, b, c}) -> ? You'll notice that there is a pattern: build S(n) -- a subset for an n-element set -- by cloning S(n-1) and adding n to the cloned sets. My comment: This is an example of a problem that can be solved inductively, but there are many problems where induction wouldn't help. Such is, for example, a problem that I was asked at a past interview -- determine if two words are anagrams of one another. It's easy, yes, it's just not inductive. Probably because we are not required to find all anagrams of each word (in which case it would be closely related to the subset problem), only to determine whether one word can be an anagram of the other, i.e. if both words have the exact same set of letters. You don't gain knowledge on how to do it for a 3-letter word if you know how to do it for a 2-letter word, because it's an exact same problem.

Pattern matching as a step decomposing algorithm questions Reverse the order of words in a sentence Write code to reverse the order of words in a sentence, e.g. "dogs are cute" to "cute are dogs". Gayle's way: This problem is similar to reversing the characters in a string: "dogs are cute" -> "etuc era sgod". The answer: reverse full string, then reverse each word. My comment: This solution sounds straight from a joke about mathematicians. How does a mathematician make tea? He/She pours water into a kettle, puts the kettle on the stove, turns on the stove, waits until the water boils, then ours the boiling water over the tea leaves. Now suppose the kettle is already boiling. How do you make the tea then? Mathematicians's answer: turn off the stove, dump the water, and now you've reduced this problem to the one you already know how to solve. I think a simpler way to reverse the word order in the string would be to split the string at spaces, put the resulting words in an array of strings, and reverse that array (many programming languages have built-in functions to reverse arrays. The ones that don't, like C, don't have functions to reverse strings either).

A ransom note from a magazine Design algorithm to figure out if you can build a ransom note (array of strings) from a magazine (array of strings) Gayle's way: What if we used characters instead of strings, and built an array of character frequencies? And generalized to word frequencies? My comment: The suggested approach doesn't seem to simplify much. I don't think it's essentially simpler to do that than to build an array of word frequencies. The key to it in any case is hashtable. Familiarity with the hashtable data structure is pretty much the only thing you need to know to keep track of how many times each word occurs, and therefore if there are enough words to put together the note you want.

Unconventional, but intuitive advice

Some of Gayle's general interviewing advice was not what career advisors typically give, but consistent with my experience. Such as: there is no need to write thank-you cards, because no candidate for an engineering position was ever rejected for not writing a thank-you card. People make a decision whether to hire you pretty soon after the interview - perhaps within a day or so -- and that's much sooner than your thank-you card could reach them. From over a hundred of candidates that she had interviewed at Google, she got only 1 thank-you card, and it did not sway her decision towards that person in any way.

Finally, do not despair if you think you did poorly. Gayle says that you really, truly can't know how well or poorly you did. Seriously, you think you do, but you don't. Candidates are evaluated on the scale of comparison with other candidates, so sometimes you might think you did really poorly, but in the interviewer's eyes you were the best candidate interviewed for this position.

Kids Code Camp, Austin, Texas, April 22, 2012

Teaching programming -- even to adults, but especially to kids -- presents you with a dilemma, all the more acute when you only have 1 hour to interest your students in the subject. You can take a practical approach: let's create a toy program that does something you like: move, bounce, play sounds. Or you can take a more-or-less exploratory approach: write some simple code, tweak various parameters in the program, and see how the computer responds. It is like having a "stick" -- a programming language -- to "poke" the computer with. What does it do when you issue this, that, and the third command to it, even if those commands don't add up to any eventual goal? I, personally, think the first approach would interest more people (especially children) than the second one. But the first one is harder to achieve. It's not easy to design a course where students would write a program simple enough for beginner to accomplish in 1 hour, but meaningful or entertaining enough to make students want to do more of this.

So it's not surprising that the Kids Code Camp -- a day long series of programming classes for kids -- took the second route.

For the first session, Ron Evans (@deadprogram) from Hybrid Group taught kids to write a few basic Ruby programs with KidsRuby. It's a programming environment that lets you easily write a simple program and run it. And by “easy” I mean it eliminates the overhead of creating and saving files, wondering what directory to save them to, how to invoke the compiler, what libraries to include, etc. It lets you run just the "meat" of the program. Not only you don't have to open a file, you don’t even give have to your program a name. Just type the program in the left pane of the KidsRuby window, and press the button "Run". The output will appear in the right pane.

Or... not.

Ron Evans gives out candy to the kids who answer questions right. Eventually he gave candy to all the kids.

The "little" problem with KidsRuby is that if you make a typo -- for example, don't close a string with a double quote (") -- it doesn't print an error message. Your program just won't run. Needless to say, for beginning programmers this makes it one of the, shall we say, least useful programming tools. If your code won't point out your syntax errors, how are you supposed to know what's wrong with it? You’ll probably lose your interest. The only way a kid could sustain interest in this is if there was an adult nearby with knowledge of Ruby, or basic programming -- or if the kid was a precocious genius, armed with programming books and hell-bent to figure out what's wrong.

Turtle.start do
background yellow
forward 30
turnright 90
forward 50
turnright 90
forward 50
turnright 90
forward 50
end


-- draws a square.

Turtle.start do
background yellow
pencolor blue
turnright 45
forward 50
turnright 90
forward 50
turnright 90
forward 50
turnright 90
forward 50
end


-- draws a diamond.

This brings me to another topic. Hell-bent precocious geniuses will eventually figure programming out on their own, but what exactly is the audience to which one should teach? The traditional audience -- kids who are interested in tinkering of any kind, in pressing buttons and typing cryptic commands just to see what they do? Those were the typical kids who studied programming. Or do we also want to teach kids who, like me, would have found such a thing mostly pointless? If, however, someone had shown me what you can make with it -- a finished object, something with a purpose, even if only a toy -- I would have been much more interested. It was via this route that I eventually discovered my interest in programming as an adult.

As I noted above, the purpose-oriented approach is much harder to teach. However, some programming environments lend themselves more easily to this approach than others. One of the sessions at the Kids’ Code Camp explored a graphical programming environment called Turtle. Its commands specify how far a colored dot has to go and in what direction, or how many degrees to turn and in what direction, in order to draw a figure you want. (Sample Turtle code is shown in the sidebar.) So you can fairly quickly learn how to write a program to draw a geometric shape pixel by pixel. I also liked how the presenter explained pixels to kids: put your nose to the screen and see if you see any dots - those are pixels.

Here's the code of What I Did on my Summer Vacation program:

holiday = ask "Which holiday?"
familymember = ask "Family member?"
activity = ask "Activity?"
smallproblem = ask "A small problem?"
puts "It was just " + holiday " "."
puts "I was with my " + familymember + "."
puts "I also went " + activity + "."
puts smallproblem + " but it was OK."
puts "It was a good " + holiday + "."


Writing a program to draw a complete geometric shape may be more than you could learn in 1 hour with Scratch, another children's programming environment that was introduced at Kids’ Code Camp. Scratch doesn't let you manipulate individual pixels like Turtle does. In this environment everything is done graphically -- programming constructs such as loops and variables are colorful interlocking widgets you snap together to “write” a program. It's best suited for creating animations involving a vast choice of cute avatars. It is very handy for explaining such concepts as loops, since you can make the avatar repeat animated motions endlessly. But programming is knowing not just how to create a loop, but how to combine it with other code concepts to achieve what you want. And to do that in Scratch, you'd have to spend more than 1 hour -- especially if you are a kid, especially if you haven't yet learned coordinate system or negative numbers. You have know that in order to tell the avatar where to move. And to get your avatar to move to a precise location, you can only do that with trial and error, by plugging in different numbers and seeing where it goes. Not exactly a riveting activity...

At one point, though, the curriculum of Kids’ Code Camp showed a hint of purposefulness. While teaching Ruby, Ron Evans introduced a "hack your homework" program. It was a ~ 10-line KidsRuby program that asked you "where, when, who, what" types of questions, and plugged your answers into a cookie-cutter essay: "Last summer I went fishing with my cousin", etc. Then it spat out a finished text that probably wasn’t worse than an average student’s homework. :-)

Muscle memory instead of a password? Maybe not for klutzes

Some day we may use muscle memory to memorize a password without even knowing what the password is, says Scientific American. To a lesser degree, we already do that in daily life, when we enter an often-used password. If we are asked to write it down, we might not necessarily remember the exact sequence of symbols. I've known people -- for example, software developers who shared a username and password to the same computer -- that could not tell a new developer the password even when they needed to, because they only stored it in their muscle memory. They could type it in, but not spell it out. Trying to write it down, they would get confused. The (still highly experimental) technique described in this article takes it a few steps further: the password consists of actions you perform in a game. I suppose it could work as long as you use it often, and if you are not a klutz like me. I don't think I could reproduce all the correct key presses every time even if I played a game often. (I am assuming here that in the game they describe, there is only one way to hit the falling dots correctly. If the game was more like Tetris, where there's more than one way to maneuver the falling bricks successfully, this technique would be meaningless.) Still, if I haven't played the game for a week, my skills would have atrophied, so there's no way I would hit the dots correctly at first. Or by the second or third attempt. But most systems worth their salt lock you out after the first three unsuccessful login attempts. So it's interesting how would such a system distinguish between an impostor, and a legitimate user whose skills have atrophied.

Pareidolia strikes

I saw this logo on a truck of an Austin party rental company. Immediately I thought, what a weird logo for this kind of business. The dude's beard and the turban would not indicate an ethnic or religious group that's known for partying. :-) And the spike growing out of his eye... just surreal. Has he smoked too many substances? Is that what the company means by "Keep Austin Partying?"

Then I realized, it's a bird. That's not a beard, it's a wing. And the "spike" is the bird's beak.

It's no wonder I prefer text-based user interfaces to graphic. I never understood why the icons in a graphical UI are so obscure and hard to recognize. At least to me, perhaps less so to other people. When I was learning image-editing programs, people would sometimes tell me to use the "bucket" (a Fill icon), but instead of a tilted bucket, I would see a hand with a mitten. I also couldn't understand why the old-time Windows Control Panel icon was a cat. Yes, a cat. I realize it's supposed to be a bunch of tools, but all those tools look like long, skinny cat's legs.

With faces, it's even worse. We humans are wired to see faces everywhere. So I won't be laughing at the next person who sees Virgin Mary in a toast.

Center For Inquiry fiction book club fall 2012-spring 2013 reading list

Update: we will have a meeting in November 2012 -- see below.

Here is the list of books we'll be discussing in the next few months in the CFI Austin fiction book club.

October 2012: Nancy Kress "Steal Across The Sky"

From amazon.com:

"The aliens appeared one day, built a base on the moon, and put an ad on the internet:

"We are an alien race you may call the Atoners. Ten thousand years ago we wronged humanity profoundly. We cannot undo what has been done, but we wish humanity to understand it. Therefore we request twenty-one volunteers to visit seven planets to Witness for us. We will convey each volunteer there and back in complete safety. Volunteers must speak English. Send requests for electronic applications to witness@Atoners.com."

At first, everyone thought it was a joke. But it wasn't.

This is the story of three of those volunteers, and what they found on Kular A and Kular B."

November 2012: Mark Twain "Mysterious Stranger". In this Mark Twain's last, unfinished novel, a young Satan comes to a remote Austrian village. He claims to be able to foresee the future and informs the group of unfortunate events that will soon befall those they care about. The boys don't believe Satan's claims until one of his predictions comes true.

December 2012: Octavia Butler "Parable of the Sower"

From amazon.com: "When unattended environmental and economic crises lead to social chaos, not even gated communities are safe. In a night of fire and death Lauren Olamina, a minister's young daughter, loses her family and home and ventures out into the unprotected American landscape. But what begins as a flight for survival soon leads to something much more: a startling vision of human destiny... and the birth of a new faith."

January 2012: Michael Bishop "Close Encounters with a Deity" - a story collection.

From amazon.com: "The book's unifying theme is man's concept of the Deity. Bishop's stories intermingle humor, horror, and awe in a manner similar to Vonnegut."

February 2012: Jonathan Strahan, editor, "Godlike Machines"

From goodreads.com: "In science fiction, nothing says sensawunda like a Big Dumb Object--a colossal, extremely powerful machine of unknown purpose and origin. It's that feeling that editor Jonathan Strahan was after when he asked six of today's finest authors to write for Godlike Machines. And they succeed brilliantly!"

March 2012: Greg Egan "Clockwork Rocket"

From amazon.com:

"Set in another universe where light does not travel at a constant speed but instead has a velocity that depends on its wavelength, Clockwork Rocket recounts the personal life journey of an inhabitant in this fictional universe."

"Alongside a taut and well imagined story set in a very alien world - complete with a sympathetic range of characters and a well imagined society - Greg Egan develops an entire alternative physics. This isn't just done in a hand waving way, it is properly worked out. The story of Yalda, the scientist who is the main protagonist, is also the story of the discovery of "rotational physics" in her universe, of the implications of that, good and bad, for her planet, and finally - in the construction of the rocket of the title - the story of the action she takes to safeguard that world."