Review: Writing Great Fiction

Every so often I get one of those Great Courses catalogs in the mail. The prices are usually tempting, but audiobooks aren't a great medium for me: I prefer reading (I can read many times faster than I can listen to someone talk). Finally, when a $6.95 deal came along for Writing Great Fiction, I decided that for the price I could give it a shot.

It took me close to 4 months to listen to the entire course, and I have to say that I'm impressed. I've long been the kind of person who understood a topic better by understanding the implementation, rather than being the kind of person who could understand the theory all by itself. For instance, I understood continuations better when I realized that it was simply allocating the activation record on the heap rather than on the stack.

Similarly, this course can be treated as a set of instructions for writing fiction, but I chose to treat it as a discourse on the implementation into fiction, which gives insight about how great fiction is constructed. For instance, I find "stream-of-consciousness" novels a complete bore and cannot bring myself to read more than a couple of pages of Ulysses or Mrs Dalloway, but James Hynes' analysis of the techniques behind those novels as well as why they're considered great made them completely comprehensible to me. (It also absolves any remaining need for me to read those books)

Similarly, he analyzes Anton Chekov's short stories, and uses examples from Alice Munro, J.R.R. Tolkein, Dashiell Hammett, Herman Melville, and James Ellroy to make various points about how to go about constructing a plot (and explains what the difference is between a character-driven story and a plot-driven story), writing dialogue, the use of first and third person narratives, and when to use narration versus painting a scene in detail. As with many college classes, he provides writing exercises at the end of each 30 minute lecture, in case you want to try your hand at some of the techniques he describes.

This is probably a great English literature class for those of you whose mind is like mine (i.e., prefers implementation over declaration/theory). I'm now even more sorry that my public University had so few spots in its creative writing courses that I was never able to snare one of the spots in those classes. While James Hynes might not be a great novelist (I never read any of his novels before starting this), he's a great instructor and quite capable of providing multiple examples for each techniques

The android Audible app (which I used to listen to all 12 hours of this course/audio book) is very well done. It remembers the state of your listening, and lets you resume precisely from where you left off at any point. I listened to this course on my android phone while hiking or doing other activities. It made a nice change from listening to music or NPR broadcasts.

Highly recommended, even for those of us who may never write a novel. This gives me more confidence to pick up one of those "Great Courses" at a good price the next time I find a deal.

Negotiation Consultancy Back In Operation

While I was working for Quark Games, I stopped accepting clients for my private services. (There would have been something wrong with working somewhere while negotiating on behalf of engineers) As of last week, however, I am no longer associated with Quark Games, so I am now reopening my service. It's good to be back!

PSA: Do take the undergraduate compilers class

We just closed our hiring cycle for summer interns at Quark. During this period, we vetted tons of transcripts and resumes from top tier universities including CMU, Berkeley, and Stanford. Our hiring standards are demanding, and I personally did a lot of interviewing. Congratulations to Kevin and Kevin.

If you're a Cal student, I have very specific knowledge of the classes offered. Once upon a time, CS 162 (Operating Systems) and CS 164 (Compilers) were considered core classes in the CS curriculum. They were required of all CS graduates. In this day of "applications first" approach to CS, CS 162 is still required but CS 164 is now optional.

From the perspective of a hiring manager, however, taking CS164 early in your undergraduate career signals several very positive things:

1. You're not intimidated by challenging classes that require lots of coding. The ability to do well in CS 164 depends very much on your ability to utilize tools, write a lot of code, and test and debug at a meta-level that none of the other classes require.
2. You're not satisfied with understanding computers at the topmost abstraction layers. You want to dig beneath the abstraction layer of a programming language and understand how they work, down to the point of producing assembly for the machine to execute. The reason CS162 and CS164 were required in the past was that digging beneath those abstraction layers was highly prized for anyone doing any kind of work. (CS152 is very nice as well, since you now get down to the logic layer --- knowing how to do anything at the transistor level isn't necessary, but it's also useful)
3. CS164 requires full use of almost all data structures you were taught in your data structures class. You'll build parse trees. You'll use symbol tables. You'll need to walk trees and do type-checking. CS164 integrates all the knowledge you got from data structures. Getting this in early in your career will only benefit you.
4. People who take CS164 will not balk at writing a parser, or even designing a whole new programming language or DSL in order to better solve a problem. This approach of meta-programming (or Meta-Object Protocols) is very useful and the skills necessary to implement it in a non-LISP environment are only available for people who know how to write compilers and other language translators.

I know it's fashionable now to deride the traditional computer science education with its emphasis on hardcore topics. But when I interview students with the traditional computer science education versus students without, the difference is clear: the former are much better problem solvers, and write better code. Ultimately, they'll make better hires and will get more and better job offers.

So for those at Cal: take CS162 and 164 as early as you can. For those elsewhere, please don't neglect your systems classes. They'll make you stronger engineers.

Wharton Business School Presentation

How to hire and keep engineers happy public from Piaw Na

I was the lunch speaker today at the Wharton Business School in San Francisco. The school runs an executive MBA program, with about 100 students a year. It's a 2 year program running mostly on Fridays and Saturdays. I gave a 40 minute talk at high intensity because I prepped for an hour with questions.

One question that came up was where can you learn to code? While I'm not a big fan of the various programming boot camps for professional programmers, for MBAs, it could very well be just the thing. The school itself had fantastic facilities, and the lecture hall was the best room I'd ever given a presentation in, with stadium-style seating and the lecturer standing in the pit subject to questions all around. Definitely an experience to be had.

As usual, the above slides are sanitized for public consumption. The presentation given to the business school students is a lot more peppered with interesting case studies from industry. Having said that, with my new full time job, my time for speaking engagements is a lot more limited and I will curtail them going forward.

Internships

The conventional wisdom on interns is that you cannot expect to get significant work done by interns: they take time to train, and by the time they leave your company, you can't possibly have trained them to the point where they're productive and pay for themselves in terms of work done.

I've led internship programs at Mpath and Google, and each time I've defied conventional wisdom. Mike Danylchuk, Alex Murkes and Carolynne Surfleet all interned for me at Mpath, and they did tremendous amounts of work. Both Alex and Mike converted to become full time employees, and were immensely productive.

At Google, Stephen Chen, Phil Sung, Matei Zaharia, and Nikola Postolov all interned for me at Google. All 4 were immensely productive, and Stephen and Phil eventually became Google employees. All these engineers made huge contributions to their projects, and more than paid for their training time.

I attribute my past successes at hiring interns and managing them to two factors:

1. I don't lower my standards when hiring interns. I interview and apply the same metrics to interns as I do to full time employees. You can do this if you focus on fundamental computer science and coding problems during your interviews.
2. I don't give interns "make work" or insignificant work. I put them on high risk projects with complete ownership of a project from end-to-end. They do the design, they code, they test, and they deploy. The sense of ownership and satisfaction with the end result gives them a hugely positive experience. This doesn't mean I just let them do their thing --- I provide design reviews and code reviews, and I provide suggestions as to which projects would be good uses of their time and talents, but providing autonomy is the key to engineering happiness.

I used to think that this modus operandi was par for the course in the tech industry, but one day I sat on a hiring committee for interns who wanted to convert into full-time employees. My jaw dropped constantly in horror at what some of my colleagues were doing to their interns:

• Putting interns on demoware, code that effectively would have to be thrown away if the data input ever had to change.
• Having interns pair program with each other, relieving the mentor of the need to code review or provide feedback to the interns. Unfortunately, this also meant the intern supervisor had no clue how his interns were doing, and whether they would be a worthy hire.
• Writing glowing reviews for an intern who did very little or next to no work (had no checkins into the source control system).

Well, here at Quark Games, we're kicking off our summer internship program next week with visits to both the Berkeley and Stanford Career fairs (we'll also consider full time applicants). I guarantee we won't' do any of the crazy things described above, and my aim is to have fully productive interns all summer. While we're only visiting these two schools because they're easily within driving distance, we'll accept applicants from any school. Feel free to send me e-mail or apply through Quark Game's site if you're interested.