We’re posting weekly transcripts of David Plotz’s Working podcast for Slate Plus members. This is the transcript for Episode 16 featuring Nina Kang, a Google software engineer. To learn more about Working, click here.
You may note some differences between this transcript and the podcast. Additional edits were made to the podcast after we completed this transcript.
David Plotz: What is your name, and what do you do?
Nina Kang: My name is Nina Kang, and I am a software engineer at Google. That means I write code.
Plotz: So, how did you become a software engineer?
Kang: I went to college in the mid-’90s. The Web was just beginning. And I was premed, but I—it turns out I have a pretty bad memory, and I noticed that a bunch of my friends weren’t studying for their tests. They had open book tests because they were all computer scientists, and if you can answer the test questions at all it’s considered a win no matter how many books you’re referring to during the exam.
That was exciting to me. I had done a little programming in the ’80s in Basic and Logo for fun, completely on my own without much help from teachers. And when I saw how much fun they were having, I decided to switch over, and the stuff that I learned in school was kind of fun. But what was really exciting was the Web. That was happening while we were there. And actually, a couple of my friends ended up getting—involuntarily having to take time away from Harvard to refocus academically before coming back, because the Web was so exciting. We were staying up all night writing these primitive Web pages in HTML. And one of the things that was most exciting about HTML is that you can teach it to yourself, because anytime you go to a Web page the browser has this “view source” command, and you can look and read what the source code is and you can copy it straight into your page. And suddenly you’ve got a copy of that page, and then you can modify it however you want. And that was—that was an opportunity to do self-directed learning on a scale I’d never seen before.
Now, these days kids have Scratch, and processing, and all of these other languages where they can do the same kind of thing. They can write programs and look at each other’s code, and there’s all sorts of infrastructure and scaffolding around helping them learn. But back then it was a pretty new concept.
Plotz: When you’re reading code, is it as clear as if you’re reading English?
Kang: If I’m reading C++ it’s clearer, because English has ambiguities and C++ is designed to have as few of those as possible. If I were to read Erlang or Prolog—which I am very much out of the habit of reading—it looks a little bit like Mandarin to me. I have a little reading knowledge of Mandarin, and it takes me a couple of seconds to process each character.
I think what professional programmers get is just the ability to really skim as fast—like, speed-reading code. The thing is that—I sincerely believe that you, David Plotz, after an eight-hour class would be able to read that code, but in order to learn how to write code these days you have to be able to Google how various code libraries work, and read what other people have written, and skim their code, and digest some sort of consensus about what it is that you should be writing. And that’s sort of an analog to speed reading, that is what you need to learn.
Plotz: So, moving from this reading to writing question, what is it when you’re writing code that makes particular code really good?
Kang: It depends on the situation and the company. Google is a very collaborative company. There were almost a thousand programmers on Google Maps. To my mind, what makes code good is that it is almost anonymous. That you shouldn’t be able to read that code and say, “Oh, you know, Kevin down the hall wrote it.” Because if he did, if it’s idiosyncratic in that way, it means that it’s not something that’s going to be so easy for other people to modify. Everyone should write in a uniform enough style within a team that we can easily grasp each other’s code and modify it.
And there are a couple of things that I look for when I’m looking at code. One of the things is, how few lines would it take for it be modified? Code that requires a lot of repetition, some people find that poetic, but I find that tedious. Because it means you have to modify it in each of the repeated places.
Plotz: What does that mean when you say some people find it “poetic”?
Kang: Computer programmers pride ourselves on writing elegant code or poetic code, but usually what that means is writing code the way that the individual programmer thinks is good, and that is incredibly subjective. I once worked with a guy who wanted to write code where every line was the same number of characters, and he would name variables in things like words, that you were leaving out vowels from, so that his variables could be the same number of characters. But nobody else on the team thought that that constituted poetic code.
I think that poetic code is code that you can read, and that means that it’s—the line breaks are in a place that makes sense semantically, that there are blank lines between blocks for functional reasons, that when something that’s going on is not particularly intuitive, then instead of comments—comments in code are pieces of English inserted between special characters that tell the compiler not to read them, and some people rely heavily on comments. But what you find when you’re working on a code base that’s changing a lot is, people will update the code and not update the comments, so they can be extremely misleading.
So what’s better than comments is code that is what we call self-documenting, where the variable names are clear enough that you can infer what’s going on without needing any English.
Plotz: Going back to this question about, you talked about that you wouldn’t want to be able to identify code as being written by Kevin. Will great coders come up with very different solutions to a problem than nongreat coders?
Kang: Absolutely. Great coders come up with solutions that are usually more concise and more easily verified. I think the key metric is, can someone else read this code and confirm that it works by building a mental model in their head of what the computer is going to do at different steps? There are certain things that are really simple, like finding out how many characters are in a line, that you could write in a way that would confuse everybody. But if your code is well-written, people understand what it does and they can tell that it works right away.
Plotz: So, elegance is—to your mind, corresponds with clarity and concision?
Kang: Yes, absolutely. Just like English.
Plotz: But in English we do pride ourselves, writers—as a writer I pride myself on having a style that is distinctly my own. Should coders pride themselves on having a style that is distinctly their own, or should they pride themselves on having a style which is so clear that it appears to have no style at all?
Kang: I think a mix of both. I think that if you have a style that’s distinctly your own for good reasons, that you’ll find other people who work with you adopting that style and your style will abruptly be less individual. And I think that’s a sign that your style is good. Literature has certain qualities that good code should never have, like deliberate ambiguity, repetition for rhetorical effect, saying things in a slightly different way when you repeat them, and I’m hard-pressed to think of why that would be good in a team coding setting.
Plotz: Are you a reader of literature?
Kang: Yeah, I have an MFA in poetry from Warren Wilson.
Plotz: Oh, that’s great. So, do you write poetry?
Kang: Yes.
Plotz: When you write poetry and when you write code, are you doing the same thing?
Kang: My poetry is actually weakened by my coding style. And there are certain poetic devices that I have a lot of trouble with using, that I have to deliberately try to force myself to use because they would make for bad coding style. Rhetorical questions, repetition, rhyme, convoluted syntax. It’s so important in poetry to be able to surprise the reader, and in coding you can surprise the reader for good effect but you want to do it through new clarity and new concision. In poetry, the range of emotions you want to give the reader—it’s so much wider than that.
Plotz: When you’re trying to solve a problem in code, how much of it is the actual writing? And how much of it is figuring out logically what the problem is and the kind of questions to ask to get it? So, how much of it is, I guess the algorithm, and how much of it is the execution and the writing of it?
Kang: That’s an extremely important question. I think that for a good coder you’re going to spend more than half your time figuring out the best way to do something, and the amount of time you spend writing what the final answer is should be, like, 10 percent or something tiny. I think a lot of us go through various drafts, various implementations. You might try a specific way of writing it, and then you look at what you’ve typed and it’s just too long, too hard for someone to understand. But having written it gives you insight into how you might revise it to make it more readable.
Plotz: What time do you usually get to work? Do you go to work?
Kang: I work in the office Mondays through Thursdays. I drop my daughter off at preschool, so I usually try to get in by 9, 10, or so.
Plotz: And what time do you leave, usually?
Kang: I leave around 5.
Plotz: Do you have time when you’re messing around and Web surfing the way, say, I do? Or are you just, like, head in the whole time?
Kang: Well, Google gives us so much latitude to design our work lives in the way we’re most efficient. So, I don’t really surf the Web very much during work because it doesn’t work for me. What I usually do is, we have these sort of—the pace of coding has a natural rhythm, which is, like, think, think, think, write, write, write, hand it off to the computer to run the code. And you pause a little bit while the computer runs the code, and you see what happens, and then you find a problem, and then you think, think, think, write, write, write again.
What varies the most among people is what they do during that interval where they’ve handed off the code to the computer and the computer isn’t done running yet. So, some people, you know, blow off steam by going and socializing, like, at the physical water cooler or in an Internet water cooler or chat board. Or they might check their email. And for years, what I’ve liked to do in those small periods of time is to make very minute, clarifying changes to the code base, because my theory is that over a period of years that builds up into a lot of work.
Plotz: The minute changes, is that brainless work or is that actually intellectually demanding?
Kang: It’s nothing exactly brainless. Like, it’s the stuff you could do in your dreams, you couldn’t do it in your sleep. There might be something that’s been nagging at you because you were working out something on Monday and you noticed that something wasn’t quite right. It’s not that it’s not working properly, it’s that it would be more readable or easier to fix.
Plotz: I guess my question—to ask that a different way, is—is that meditative work for you?
Kang: Yeah, it’s absolutely meditative work. It’s relaxing and it gives you that little dopamine hit of having done something.
Plotz: What do you think you would be doing if you weren’t a coder?
Kang: Well, I actually took three months off and I wrote an article for Salon. I’ve found writing essays pretty rewarding but not as rewarding as coding. It was just so open-ended and you don’t have that sort of tight collaboration with the computer to validate you. And I did a little yoga, and I did gardening. Now, pruning and weeding is a lot like coding, especially maintenance coding in a company like Google. I have this grapevine and it’s sending out tendrils very aggressively, and the way the vine works is, you know, it might have three different stalks and each stalk is sending out tendrils almost at random. The tendrils are twining on each other, and even though they don’t need—the vine stalks don’t need each other for support, they’ve ended up in this sort of tightly-nested space. And that’s actually something that can happen to code, especially in a company as big as Google. You don’t want to write this one function. You’ll see that someone else on another team wrote a function just like that, and you go send out, you know, a reference, and you link in that function into your own code.
Now, the other person wants to change their function and suddenly they’re stuck. They can’t change it too much without changing your code, too. And now they have a pickle, and the process of untwining those little tendrils and chopping down my stalks felt a lot like what I have to do to decrease other people’s reliance on my code sometimes.
Plotz: So you’re a woman and you’re a software developer. Do you think there is any way—you obviously work differently than other people because you are a different person than other people. Do you think the fact that you are a woman has any relevance to thinking about how you work differently, or your working style, or what you’re good at?
Kang: I don’t think there’s anything in me that makes me different from a male programmer. I do think people relate to me differently because I’m a woman. One example would be—especially now that I’m a mother, one role that people feel very comfortable—women leaders need to be in certain slots for people to feel comfortable, and one of those roles is the maternal role. So, if I am going around asking people, have you done your work yet, and I’m doing it in a way that they can see is motherly, it’s more comfortable than as some young woman trying to nag them.
Another thing is that there is sort of an expectation that women will be better at collaborative tasks, at mentoring, at documenting and explaining things, and there certainly have been times in my career when I was good at those tasks. And there would be other year periods where I was in a more solitary mode for whatever reason. And definitely I think people can people relate to me like they understand me better when I’m slotting in to those sort of pink skills a little more clearly.
