Interview with Rachel Vincent

& (verbiage overflow)Wed 11 May 2016RSSSearchSubscribe

Conducted May, 2016 at the Recurse Center.

RHV: What got you started programming and why did you come back?

DPB: My mother moved me to a new school in 1975, when I was 13. There I was exposed for the first time to programming and to Latin, subjects foreign to me that I still recall today as tokens of life in a much healthier environment. The middle school computer teacher was a young woman and the class was coed. She taught us BASIC, which ran on an IBM 1130 mainframe with an “input hopper” for reading punchcards and a “lineprinter” for output; there was also a “console typewriter” for some input and output. By 15 I was stewing happily in Latin and FORTRAN IV, and remained so until I graduated. I did most of my coding using punchcards or, later, on a paper terminal connected to a PDP11, sometimes staying in the computer room into mid-evening to do so. I also owned a programmable calculator for which I could write a sort of procedural bytecode language, each code corresponding to a discrete keystroke on the calculator.

The new school adhered to the relic of a progressive educational philosophy, one of those that originated around the First World War and akin to the later Unschooling movement that now vivifies RC. Students had unstructured “lab” time scheduled every day, during which we were supposed to meet and study one-on-one with teachers, on the basis of “contracts” with each of them. But I discovered that at these times I could vanish into the library (which was enormous and boasted a complete set of Loeb Classics) or the computer room, and the Powers apparently considered me to be operating within appropriate parameters and left me alone. In retrospect, this liberty and this access to books and computers infected me with the spore of the “questing” life — the life spent in study.

So a lot of the time that I spent within the walls of my high school was invested in FORTRAN and Latin. But after graduation I abandoned them both for new loves. In college I immersed myself in Chinese language and articulatory phonetics, and after working for a while on a program to simulate the ritual of consulting the Yìjīng (“I Ching”), I gave up programming altogether. At the time I had only experienced strictly procedural programming — little more than scripting — and I had no more than the dimmest notion of basic things like time complexity and memory allocation.

Chinese and phonetics required assorted technical skills, skills I reveled in, but none of them were in any way automated. Proficiency in Chinese combined perhaps a half-dozen challenging skills involving reasoning and different sorts of memory (including kinesthetic memory and memory for pitch), and I turned out to be good at most of them; articulatory phonetics depended on one’s ear and tongue, and mine were sharp. I forgot all about procedural programming and eventually went on to graduate school to study at the feet of authorities in Chinese dialect classification, historical phonology, and general sinology (the philology of traditional Chinese literature). My dissertation advisor treated me in the traditional way of the Doktorvater that I think almost no one in the sciences and engineering ever encounters now — like a beloved child and colleague. For my dissertation research I spent a couple of years in the Chinese countryside, sometimes in places without electricity, documenting obscure dialects by hand and ear in order to study linguistic history in the region. I returned with a great mass of data, hand-written on paper, that would have to be manually collated.

My return to programming, or it would be better to say my eventual awakening to it, began when I was writing my dissertation in 1996, and got fed up with Microsoft Word. Word v5.1 did not handle the Chinese script or the International Phonetic Alphabet (IPA) satisfactorily, and the more advanced v6.0 would not run on my low-end laptop. I could write my own IPA font using special font-design software, but Chinese was a real headache — we graduate students passed around samizdat copies of Taiwan software and used hacks to support non-Western scripts. As a replacement for Word, I stumbled on the small application Nisus (still in production today), which supported multilingual word processing in the era before Unicode. Nisus’s search/replace tool used Perl-flavored regular expressions (regex), which I learned by trial and error and found very stimulating. Incorporated into in-application “macros”, regex let me write procedural scripts to search or edit the text files where my dialect data was stored.

But I really discovered true programming only in 2009. By then I had become a professor at a university, gotten tenure, and left my professorship after coming to suspect there must be more interesting challenges for me. I went to work in the tech industry, in a machine translation start-up, holding a responsible but relatively non-technical position. When the company closed after the 2008-9 economic collapse, Norman Kabir told me, “You should learn to code,” and being at loose ends I did, at age 47. I started learning Python, very hesitantly, dabbling with manipulating Chinese strings in Python 2, which forced me to learn about encodings. I was lucky to be taken in by Gloria Willadsen, who had founded the New York Python Meetup and was mentoring a few people at a time in Python in order to foster best practices. I felt I should try to get some sort of formal training, and so matriculated as a second-degree Engineering undergraduate at the City College of New York (“City”) in 2010. I soon decided to attend part-time, giving as much energy as I could to each class in order learn the content reasonably well (rather than skimming, as many undergraduates are forced to do). I was adjuncting to pay the bills, doing a lot of sinology and getting things published that I had had to put on hold earlier because of the academic grind, but in three years I finished the seven courses that made up the Computer Science (CS) minor, while teaching, publishing, and so on. It took me a while to find out, though, that in a CS program you learn CS, not programming. CS consists of things that are useful to programming, though. I only really started coding every day, following my own program of study, about a month before I came to RC — I was fifty at that point, at the end of 2012.


RHV: What were those “things that were useful to programming”?

DPB: The most important ones were discrete math, data structures, and algorithms. I also gained from courses in probability theory and theoretical computer science. I am not very good at math, but I worked hard and managed to do well in them. There were also two hands-on coding courses in the core curriculum, and I have come to doubt their value. For one thing, articulation between them and the more theoretical curriculum was poor.

But those first five courses I mentioned I would recommend to anyone who wanted to enrich their programming life — they have all proven deeply useful, and it’s hard to describe what a pleasure it was to study them.


RHV: What’s the most frustrating day or event you’ve ever had as a programmer?

DPB: There have been too many to name. Being frustrated is a regular part of my experience while programming.

One case that springs violently to mind happened during my last class at City, just before I joined RC — a course in Java and Android. I thought I would start learning the Android material by trying the official Google introductory tutorial. And the code it supplied didn’t work — I spent days and days and eventually identified five serious errors that had to be corrected before their code worked as prescribed. I learned a lot from the exercise, but the frustration exceeded whatever satisfaction I had. After that, I managed to write an app, but I have never felt like working in Android again. I’d rather work with tools that seem carefully maintained and documented.

I like detail, I’m curious, and I’m stubborn — that combination makes me willing to dig interminably for answers. It is not an unusual mix of traits but I think I have it to a severe degree, and it taints much of what I do. Among other things, it makes me slow to ask for help, to my detriment.

If I ever learn to give up sooner and ask for help, I’m sure I’ll be a better programmer. One of the signs of being a good programmer is observing yourself to be flailing. That is why programming seems much easier when you’re pair-programming, because you can see the other person flailing and then easily conclude that you, too, must be flailing. But when you’re alone, self-observation is difficult. So a day goes by and then another, and you’re still struggling, or perhaps your struggle has branched off into some sub-struggle or meta-struggle or para-struggle, or all of these at once. Pairing is much more efficient than by just a factor of two. Your learning is deeper, and there are many more lines of experience running into your mind — you are reading your partner’s body language, which includes responses to your own body language, and all sorts of useful things are happening.


RHV: How has your background in academia informed your approach to programming itself and to learning new things in relation to programming?

DPB: People often think of me as an academic who moved into coding. I don’t think of myself that way at all. The mix of traits I’ve described above — love of detail, curiosity, and stubbornness — has led me to, among other things, an academic career and coding life. But I think it has led me to each separately.

In the earlier, “typewriter age” when a lot of my learning habits were formed, it wasn’t always easy to go and simply look things up. Reference books, if you had access to them, were selective by nature, and sometimes you didn’t have access to them at all. You couldn’t necessarily just go get whatever you wanted, because you didn’t necessarily have access, and sometimes it wasn’t obvious at all where you would have to go to get what you wanted to know. That affected the kind of searching you did for information — you did not automatically assume that you could or would find it. I have the feeling these days that computational resources lead me to use my mind in ways that are different from how I did when there were only paper resources — I have the impression that paper resources required more factual and spatial memory and less reasoning and kinesthetic memory. I have an idea that programming involves, for me, nothing less than my kinesthetic imagination as a form of visualization. (Actually, I have the same experience when reading Classical Chinese.) But I’m not sure how that affects programming itself. And it’s easy to imagine today that everything you want to know is somewhere on the Internet, if you just phrase your search query the right way. I’m pretty sure that sensation, vivid as it is, is quite wrong.


RHV: Do you find parallels between programming as a practice and academic research? or life in academia in general, if not research?

DPB: I understand you’re asking about social issues rather than how we establish what is true — about the Thomas Kuhn angle rather than the Karl Popper angle. One point is that industry is a lot more hard-headed than a Humanistic department in a university. Another point concerns collaboration. And then there’s the question of power dynamics among people.

First the question of hard-headedness. College professors, especially after tenure and especially in the Humanities, often think of themselves as independent contractors — they may go for decades without any supervision or validation of their teaching and research. That is very different from the experience of most programmers in a company, where your work contributes to a collective business product and where anyone not meeting expectations may be dismissed without warning.

Teaching may sometimes require you to adhere to some external syllabus or rubric — but in my courses, from graduate school onward, I don’t think there were more than ten occasions, over about 25 years, when a visitor sat in one one of my classes to make a neutral observation of how I taught. When I ran my university’s Chinese Program I strongly encouraged all language faculty to observe each other’s classes regularly, but that was done for mutual enlightenment, not critical evaluation. In research, I never had to worry about meeting external criteria imposed by funding agencies — what few grants there were in my stone-cold fields generally went to an individual for individual work, and as a professor — in theory, at least — I had plenty of time to work on whatever I wanted. (I say “in theory” because in practice, as head of the Chinese program, I had a lot of administrative chores to discharge, and those cut into my research time.)

On the other hand, academic programs where graduate students live on funding from their professors — these are much more common in the sciences, engineering, and power-oriented fields like linguistics and education — are quite different from what I experienced in an unmodish Chinese philology program. In a hot field, there are satanic quantities of paperwork to be done, budgets to be planned and expenses justified, and a participant who fails to fulfill expectations may be sacked.

Now, as to collaboration. My academic research life was solitary, apart from fieldwork. I didn’t learn to collaborate on academic projects until after I left academia. I think collaborating on programming projects is easier — it’s certainly more accepted among engineers than in the Humanities — although it’s not easy to find coders who want to commit with whole heart to a long-term but possibly non-commercial collaboration.

Power dynamics between people seem to me about the same in both environments — there’s a lot of chitchat and wasted time, unless you take care. There are servile flatterers in low positions and stuffed shirts in high positions. There are “honeysuckles” (and other climbing creepers) at all levels. And human beings generally pay more attention to prestige and reputation than to substance.


Although you’re asking a Thomas Kuhn question, I’m more interested in the Karl Popper reading of what you’ve asked: what strategies can we use to establish knowledge? Briefly, I can think of three. First, software testing has a lot in common with hypothesis-falsification, an important feature dividing good scholarship from bad. Second, theoretical computer science seems to offer models for exploring formal symbolic systems, one of my sinological research interests — how do things like the Chinese “rime tables” (děngyùntú 等韻圖), the Chinese script, or the Gwoyeu Romaztyh 國語羅馬字 romanization system actually represent the things they do? Finally, the coder ideal of favoring “primary sources of truth”, which I discuss later on, is congruent to the practice in philology of consulting either primary or standard sources, rather than derivative works whose relationship to the originals is uncertain.


RHV: What is your approach to learning, let’s say, a new programming language, as when you had to learn Python?

DPB: When I learned regex, I did so entirely by futzing — I didn’t even know it was a real (and efficiently elaborated) system — I thought I was figuring out some arbitrary notation invented by the Nisus developers.

When I decided to try Python, I bought a couple of simple-looking books and started writing code immediately. I didn’t do a tutorial — I got reference tools and tried my hand at the code directly. Within about six months I had discovered David Beazley’s Python Essential Reference, which I carried with me all the time and read in whenever I had a free moment (just as when I was in graduate school I carried the reduced-type Tsyryuan 辭源 dictionary with me all the time and read in it constantly).

In the time since then, I’ve tried tutorials many times, but I don’t think they’ve ever worked satisfactorily for me. What they promise is attractive but I always end up disappointed.

As I observe myself, it seems I combine two activities when I learn. One is to dabble and try things out with my own paws, sometimes indulging in compulsive-looking repetition. The other is to sketch out a kind of system that encompasses what I am learning. I sorely need system, but apparently I also need to organize it myself. I’ve often tried using pre-fabricated schemata for what I’m learning — that was true in my study of Chinese historical phonology and Chinese medicine, too, in earlier lives — but it always turns out that I can’t do much with a systematic scheme unless I’ve composed it myself.


RHV: How has academia affected your approach to programming itself?

DPB: The effects of my scholarly life on my approach to programming are a problem for me. I’ve tended, when left to myself, to work in the domains of expertise in which I made my original academic career. Those domains still interest me very much, even though I don’t make a living in Chinese any more. I mean questions involving Chinese diction or the ordering of sound in Chinese literature — these interest me a lot, and computers can spare me vast amounts of benumbing, repetitive manual labor and answer my questions efficiently. So the kinds of projects that tend to attract me in practice are ways of making manual work efficient, not the sorts of things that fill other programmers with awe at my craftiness.

I would have been wiser, in my second batch, to break away from my expertise and maybe even from every language and tool I was now familiar with, and to dedicate those three months to working in ways new to me — say, only with images, or only with color and shapes. That would be an act of self-fertilization, manuring my own roots. Partly, I return to sinology problems because there are so many sinological questions that I’m still interested in asking, and of course you can learn a lot even by writing code to support an expert domain, rather than just solving puzzles in which you don’t have an emotional investment. But it isn’t healthy that I’ve rarely broken out of my home domains — it means that I’ve tended to let my past interests inform my present work, and I’m now certain I’ve done that too much.


RHV: Are you still getting a lot out of projects like that — are you holding yourself up to where you could be if you did these very different things and seeing that you’re not still growing as a programmer because you’re working in this one sphere, or are you still growing as a programmer even though you’re working in this one sphere, and that’s why you’re loath to jump out.

DPB: There are several factors to think about: growth overall, growth surrounding familiar tools, and growth in non-programmatic matters supported by programming.

Yes — at this stage of my life as a programmer, in order to grow most overall I must work in some language other than Python. It’s like walking in New York — it’s enormously stimulating but if you want it to remain so over time, at some point you have to start varying your paths. If you’ve been up and down all the long north-south streets, at some point you have to start walking across the island the short way. That’s one aspect to the situation you’re asking about: recognizing the need to wrench oneself into a new paradigm so as to grow in a different way than one has before. RC wisely advises junior programmers to get control of one language very thoroughly, first of all. But exactly when to take on another language is harder to decide.

The BASIC and FORTRAN and bytecode-language that I studied in childhood and the regex-macros that I found myself writing in my thirties share a purely procedural style. It’s possible to write Python the same way, as a scripting tool or with functions (the FORTRAN I learned had “subroutines” rather than named functions). Even in object-oriented style, it’s common for Python methods to be basically procedural, internally. More abstract styles of coding — recursion, higher-order functions, asynchronous execution with callbacks — are possible in Python, but it isn’t clear to me how often they are necessary in the service of your average, practical use case. I have no facility with mathematical puzzles or abstract board games, nor even much interest in them, and I think the puzzle-and-game mindset draws some people to abstract styles of programming much earlier in their coding education than happened in my case.

But that is not the only dynamic in play. Working in corporations for the last year and a half, I’ve learned a lot of tools new to me. Even in Python, I’ve learned some tools and techniques that you tend not to learn when you simply “learn Python” proper. I’ve also learned production tools that I think must be almost impossible to learn outside of a working production environment. That’s another aspect to the situation: I’m certainly growing as a programmer, even though I’ve continued working in Python. I think it would have been out of character for me to have gone on quickly to another language after Python. I tend to perfuse myself with whatever I study. When I imagine myself as a complex computer program, I think of this trait as a depth-first search algorithm.

A third dynamic is this: my research projects are all cases of application; the code is not the important thing. So the code is often much simpler than what I write when learning an algorithm or a new tool, and with good reason: I’m pursuing a different kind of discovery. The research problem isn’t usually so much hard as it is tedious, and the computer lets me answer some questions by doing repetitive tasks for me — something I couldn’t feasibly do by hand. That makes possible kinds of research of great interest to me, but in those cases I’m learning more as a sinologist than as a programmer. With the computer I can pose questions that I couldn’t have posed before, or anyway couldn’t have answered. For instance, there are questions about Chinese usage and prosody that I thought of in the 1980s and only recently became able to answer because I can code. So that’s another aspect to the situation: some of my growth is as a sinologist, and that’s acceptable to me. I think I am in the minority among engineers I know, in or out of the RC clan, in maintaining a life-activity whose level of complexity is that of a career, yet intrinsically apart from programming. I learned to code in the service of that activity, and it’s necessary for me to continue to grow in it.

In sum, I think I’ve delayed one kind of growth that is important to me and that RC considers distinctive of the experience here, but I’ve grown nonetheless in other respects that are considerable — it hasn’t been a waste to have proceeded the way I have, but I find the pressure within me to learn more abstract styles is getting strong.


RHV: You have done two batches at RC. Before your first batch, what were your expectations of what RC would be like?

DPB: Actually, I now realize that I had no idea what I was walking into.

I would summarize the issues as: meetup culture, skill-level and pairing, generational differences, community, and socialization. And the greatest of these was socialization.

Meetup culture. I heard about RC in mid-September of 2012, after the media blitz surrounding the Summer ‘12 batch. I had to wait two and a half months for the application-window to open and then applied, with no way to estimate my chances of getting in — I assumed the application queue would be mobbed with the kinds of people I met at the various coding meetups. It was not. But meetups were the only model I had, apart from the ACM club at City College, for how programmers might interact socially while also technically. The model was no use. RC turned out to be entirely different.

Skill-level and pairing. I knew that batchlings would be at different levels of skill and that mine would be relatively low, and I also thought there would be a lot of interaction between batchlings of different levels — there was much less of that than I expected. I did much of my work alone, rarely pairing. I remember that I felt both surprised and intimidated by some of the pairing that I observed between some parties from the very first day on — it involved people not just sitting together but sometimes located in different parts of the room yet still working together and calling out to one another. It seemed ostentatious to me. In practice it was harder than I expected to get people to pair with me during my first batch.

Generational differences. That I would be older than most batchlings, I expected — actually, I was the oldest person to attend RC up to that point (though I’ve since been bested). I don’t remember being fazed about that at all — for the previous three years I had been taking college classes, and I was used to being around much younger people. The average undergraduate in my classes at at City was, I suppose, about 20, with a few people up in their thirties; the average age at RC was around 28, and the range in my batch was around 20-48, not including me. But an interesting difference was that at City, the professors (ages around 30-60) were my social peers — I could talk to them about grading policies and pre-tenure strategies and handling plagiarism, even though technically I was studying under them as an undergraduate. In that environment the young were my fellows, but as undergraduates our relationships were subtly competitive and we had relatively little interaction with one another, even though I joined the ACM and served as chapter secretary for a year. At RC, however, the young are my social peers and collectively we are each other’s teachers and students.

There are sometimes small accommodations of attitude that the young and I have to effect in order to “make room” for each other — it’s useful for me to remind myself that doing so is as much my responsibility as theirs. Certainly, it’s been an education and a privilege to enter a peer-group that includes many, many batchlings half my age.

Another aspect of the age issue is that, when I entered, neither RC nor I had any idea how hard it would be for someone senior in years and work-experience, but junior in coding, to be taken seriously for jobs in the tech industry. However, to any fellow “old” people reading this (especially career-changers over 45) — my advice is that persistence is much more effective than despair. It’s also more pleasant, for us and for others.

Community. The chat-client Zulip (then called Humbug) was not introduced until my first batch. Having a really good internal chat-client enabled the kind of communication that made the community possible, so at the time of my first batch I didn’t expect, and even RC’s founders didn’t yet realize, that the community would turn out to be the crown jewel of the whole RC movement.

Socialization. I didn’t anticipate how much I would become socialized as a programmer. I had no idea there was even any need for that to happen. But it turned out to be my primary area of growth during my first batch. I don’t mean I didn’t also learn a lot of skills — I learned to write tests, I learned to write SQL properly, I learned how to use an API, how to scrape websites, how to use a range of libraries; I learned a little JavaScript and did a bit of SICP in Racket. I took part in code reviews with Zach Allaun — he even let me sit in on reviews he did of other people’s code, a great education all by themselves. But the primary thing that happened in batch was that I began to think of myself as a programmer, and to understand what that meant. That did not happen during my three years of study at City; it didn’t happen when I was writing FORTRAN in high school — I wasn’t aware till some time after my first batch at RC ended that there exists a “programmer” mindset and that a person could adopt or cultivate it, that there were things you had to make your mind do in order to learn and adjust to this work and its culture — and to realize that I had already begun doing so. I had imagined that I was going to RC to learn new programming methods or improve at those I already knew, and while that certainly happened, it wasn’t nearly as important as my socialization.

RHV: You mentioned that you cultivated the mindset of a programmer in your first batch. How would you describe that mindset?

DPB: Programmer culture expresses itself through many memes (in the original, Susan Blackmore sense of the word). Some of those I became alive to through RC are best practices, prototyping, openness to jargon, and avoiding tertiary sources of information. Two of those can be covered quickly. First, best practices. Python has exceptionally well-described norms, but during and after my first batch I gradually caught on to the fact that the several facilitators who specialized in it had different coding habits. The lesson for me in that was to look to the prescriptions and the practice in Python’s docs and sourcecode, rather than to trust the expert advice I got from anyone, albeit given in good faith. Second, prototyping. Because RC is a learning rather than a production environment, it was useful to set a project aside as soon as I had “made the point”, rather than trying to bring it to a perfect state. One of the things RC seems less suited to is learning production techniques. Thinking of my projects as sketches rather than finished works has been helpful for making the most of limited time during batch.

Jargon. During my first batch I made progress overcoming the psychological obstacle of jargon. One of the signs that you are not yet socialized as a programmer is a feeling of unease when trying to draw breath in the terminological miasma of modern coding life. I learned to do this by noticing technical jargon, recognizing it as jargon, and remembering it, even if I didn’t yet understand it. Sometimes, when I now encounter a new term, all I really have time to do is to make a note of it and its context — as though I were encapsulating a function’s state-environment in a closure — for later reconstitution.

A lot of programming terminology is arbitrary. There is almost no way the name of a language or framework could be otherwise, and in our time these things are burgeoning like strains of bacteria in a damp, dark place. But even when a term has a straightforward motivation, that motivation tends to be hard to retrieve without special knowledge, and so transparency is defied. Think of “currying” a function — it is named after a mathematician and has nothing to do with putting a horse’s hair in order or making an egg more interesting. Think of a “lambda” function — it was meant presumably to suggest the initial l (Greek λ) of logical, in lambda (= logical) calculus.* And why do you suppose time complexity is represented with a “big O”?**

[* A comment by Lindsey Kuper let me to an unsourced remark by Henk Barendregt ("The Impact of the Lambda Calculus in Logic and Computer Science", The Bulletin of Symbolic Logic, 3/2 [June, 1997]: 182), to the effect that λ was an accident propagated from to ⋀x to λx. I'm dubious, as the circumflex was common in the era of lead type, and it's hard to imagine it not being to hand or being hard to position. Also, I think it was rare to use recognizable letters without their standing for a word in someone's mind.]

[** I've given my thoughts about the origin of 𝑂() in a review of Roger Hart's The Chinese Roots of Linear Algebra (Journal of the American Oriental Society 131[4; January 2011]: 652-655), p. 654.]

Using jargon is a sociolinguistic tactic for delimiting an in-group from out-group, so with that in mind, junior programmers should exert themselves to neutralize this obstacle. I began to be aware that this was possible for me during my first batch, and that doing so was part of the programmer mindset.

Avoiding tertiary sources. Another aspect of programmer culture is to avoid derivative sources of truth, even when they are convenient, and to prefer secondary and primary sources when feasible. I did not really start to understand this point until my second batch, and it has only been in the past year that I have come to feel it in my marrow.

One of our goals as coders is to try to formulate a model of how any particular tool works. What are our options for that? Exploring the tool first-hand is a common way to form that model. Native docs are an important source, although they are secondary — as are comprehensive reference works. A more difficult way, but a powerful one, is to examine the tool’s own source code — source code is the ultimate definition of what a piece of code does, so this is the most direct path we have to forming our model.

It’s common for programmers, when they’re puzzled about something, to turn first to derivative sources on sites like StackExchange or Quora, where you can read answers, and sometimes very good ones, to your questions. Googling an error message is a very common first step in debugging. But while going to a derivative source often gets you an answer quickly, it’s also the worst option from the point of view of learning, because you can get an answer without, usually, contributing to your intellectual model of the tool. (Blog posts can be an exception to this.) Part of what I understand as the programmer’s mindset is to cultivate the discipline of playing with the tool using your own hands, consulting the docs, and perhaps reading the sourcecode — all before visiting derivative sites. Learning from primary and secondary sources is easier now than it once was, because there are now REPLs and code sandboxes for many languages; many libraries and applications now have open-source code. Among secondary sources, man pages go back a long way, but now we can also read docs on the web or packaged into apps for mobile devices; there are also GUI-based doc-readers.


An aside: How about a “locked-box Recurse Center”, an “RC @ Sea”, where the participants would have no access to the Internet for, say, a three-month batch. We would have only source code for the tools we chose to bring with us, built-in documentation for those tools, and each other to consult if we wanted to understand something. No StackExchange or other third-hand sites — in fact, even at second-hand, ideally nothing further-removed from the code itself than built-in documentation. The goal of this disciplined exercise would be to cultivate resourcefulness.


RHV: Why do you choose to program?

DPB: I don’t think I choose to program; I usually have something within me that just has to come out. I don’t choose to write prose, either. There seems to be a kind of compulsiveness involved. Neither the code nor the prose necessarily comes out easily, sometimes I can’t get into the state of mind to do it, or get the “things” to form correctly, but there are these “things” that have to come out and eventually they do.


DPB: What’s your goal in doing this?

RHV: My goal in doing this is to collect as many different origin-stories of people, as programmers, of the RC community, as possible. Because I think that in the scheme of communities of programmers we have a lot of very interesting ones, and it would be very nice to share them because I feel that programming still has a mystique about it — it seems that programmers are sort of “other’ — they’re often lumped in with “genius astrophysicist” and things like that: “I could never do that.”

[end]



All articles

  1. John Holt on learning in mid-life and the role of the teacher (1976)
  2. What goes in a README?
  3. Self-segregation
  4. Python decorators for object-oriented method behaviors
  5. The English Level of This Year's Principal Presidential Candidates
  6. Chao on Wenyan
  7. Face 面子
  8. Some Questions about the Recurse Center
  9. De-duplicate Apple Calendars on Mavericks
  10. Transcribing Voice Recordings on OS X, 3 — another example
  11. Transcribing Voice Recordings on OS X, 2 — more examples
  12. Transcribing Voice Recordings on OS X
  13. Interview with Rachel Vincent
  14. The Pre-Morse Origin of Two Morse Code Symbols
  15. “The Man Who Knew Infinity” — 2015 movie about Ramanujan
  16. Why does Python have two ways to filter a comprehension?
  17. There is no ternary operator in Python
  18. Does Fortran have a two-way decision function?
  19. Debugging the Art Museum
  20. Learning to Throw Books Away
  21. About Me
  22. Walter Murch on Standing at Work
  23. “Our Kind of Story”
  24. Revisiting the Taiwan national anthem
  25. Review of Button, Phonetic Ambiguity in the Chinese Script
  26. Importing Modules under Pytest
  27. Two Git Accounts on One Computer
  28. Pytest parametrization — passing multiple data-items to a single test
  29. Markdown Basic References
  30. Two Curious Things about screen.width and screen.height on Mobile Firefox and under iOS.
  31. Where Do I Stand on Digital Advertising?
  32. Progressing to the Next Level after Two Years at Hacker School
  33. Health Insurance $5,600/year ⇨ $12,600/year to Keep Our Doctor
  34. Always Use Dry-run Options If Possible
  35. Basic Interaction with Man-pages
  36. Taiwanese Cantillation Prosody and the Standard Tradition of Regulated Verse
  37. Automated Transcription of a Lyric’s Melody
  38. Quote-Unquote: Quick Python Conversion to and from URI Standard Format
  39. Literate Code in Crista Lopes’s Exercises in Programming Style
  40. Special Computer Help for an Uncooperative Person in Need
  41. Richard Bellman on Multistage Decision Processes
  42. Contradictory Advice from Kenkō about Studying after Mid-life
  43. Deceit for my Mother’s Sake
  44. New York State’s Law on Intercoms
  45. Our Relationship with Unwelcome Callers
  46. Reasons to Keep a Landline Phone
  47. Chinese (Pinyin) Tone Marks on Macintosh
  48. Suicide by Holding the Breath in the Greek Classics
  49. Transcribing a Solo Voice Recording to Western Musical Notation
  50. Surprise Text Message Sent by Google Voice
  51. Trimming a Git Repo before Moving It to GitHub
  52. The Sage Chilōn on Gesticulation
  53. Examining the Identity of a “Whole-Sliced” Python Sequence
  54. Pagerank after Completing the Move of My Blog
  55. Haydn on Originality
  56. Stages of Life
  57. Linguistic Naturalism in Behavior-Driven Development
  58. Some Advice on Interviewing in China
  59. The AARP on Ageism
  60. The Cash Value of a Lost Moment
  61. How Did 釁 Get Into My Computer? A Talk at CSTUY
  62. I Knock My Head on the Ground: Review of Richter, Letters and Epistolary Culture in Early Medieval China
  63. Two Pair of Suspenders Back to Amazon
  64. Knuth on the Direction of the Tree in Computer Science
  65. Py3K Versions of Networking Programs for the Rhodes and Goerzen Book
  66. A Fake Monk in Times Square
  67. Werner Herzog on the jungle’s “articulate obscenity”, “misery”, and “sort of harmony of collective murder”
  68. Hacker School and How we Learn
  69. Hacker School Sees “The Internet’s Own Boy”
  70. Two Chinese manifestations of black cardamom
  71. A natural-language URL shortener
  72. Recovering Web and Search visibility after Leaving WordPress
  73. Greedy evaluation in Python's default dictionary
  74. Trying to Change Google Pagerank after Moving my Blog
  75. Ensuring my blog is indexed by Google, using Webmaster Tools
  76. 'Dependency' in programming means the opposite of its traditional meaning
  77. Experimenting with a Site-Analytics Tracker
  78. Unexpected Behavior from the Python 3 Built-In Hash Function
  79. Rote learning and programming
  80. r0ml on the workspace-based, image-oriented programming paradigm
  81. In technology, knowing your vulnerabilities is a desirable strength
  82. The Lingering Puzzle of yán 焉
  83. My grandmother’s diaries
  84. Scholarly Presentation: Arousing something other than polite interest
  85. Friedrich Gulda's Beethoven
  86. Reaction to Jaron Lanier Talk at Cooper Union
  87. Yuen Ren Chao on Chanting Chinese Poetry
  88. The legal requirement of having a camera inside a NYC taxicab
  89. This blog has moved
  90. "Web of Trust" in Chinese and Japanese
  91. Taking the larger view of frustrations with technology
  92. Reflecting on Bernard Baruch, on the need for character and thinking
  93. Dinner with a Bletchley Park cryptographer
  94. Karl Popper on conflict between your basic assumptions and those of your interlocutor (1965)
  95. My Hacker School Pairing Interview
  96. Thirty political parties fielding candidates in New York City this election
  97. The world's only speaker of standard Mandarin in 1923
  98. Data within literal curly brackets using Python format()
  99. The Imperative Style in Commits and Docstrings
  100. Git overwrites file metadata including creation and modification date
  101. Two complaints and one word of praise about GitHub Flavored Markdown
  102. Lǐ Bái on time (8th century)
  103. Two bits of trivia from the Institute for Advanced Study
  104. Karl Popper against foundations of knowledge (1965)
  105. George Orwell on falsification of fact (1946)
  106. Loss of innocence for "ggg"
  107. George Orwell against uniformity of political principles (1946)
  108. Library technology at the Institute for Advanced Study
  109. Richard Feynman on scientific integrity (1974)
  110. Richard Feynman on ignorance of science (1964)
  111. Tense in Git Commit Messages
  112. A better plan is needed for transporting equipment in the subway
  113. "Premature optimization" as phrased by Musashi
  114. Finding and returning zero or one of a marked sub-expression in Python regex
  115. A faster Python sort
  116. A question about time complexity when testing membership in a Python nested sequence
  117. Rendering a matrix as a linear array
  118. Attempting a generic SQL INSERT statement in Python
  119. Welsh bwg 'bogey': an alternate proposal about the origin of "computer bug"
  120. Using python str.format(*args) when the cardinality of *args is unknown
  121. Compelled by forces I can no longer resist…
  122. Highlights of the July, 2013, NY Tech Meetup
  123. Review of Zádrapa posted
  124. Now filtering (> /dev/null) some spam before it reaches the Gmail Spam folder
  125. Isaac Newton, creationist
  126. Freeman-Halton 3x3 exact test
  127. Conjure me: reentering the zone of proximal development
  128. Python extend() without a list comprehension
  129. The name "Hacker School"
  130. The benefits of Hacker School
  131. Another two subway rules of thumb illustrated
  132. Short-circuiting and (and ==) instead of if in Python
  133. Quintilian on time and study
  134. Kenkō on time and study
  135. George Orwell on keeping a diary to cultivate dispassionate thinking
  136. A bon mot of Quintilian on theory
  137. Growth of outlook at Hacker School
  138. Nakamoto Satoshi, the name of Bitcoin's inventor
  139. The psychology of pairing and code review at Hacker School
  140. Computer science and rugelach
  141. Is Hacker School like graduate school?
  142. Why do I work so hard at Hacker School?
  143. Hacker School compared with studying computer science at City College
  144. Differences between code and natural language
  145. Hacker School after six weeks
  146. Pairing at Hacker School
  147. The Norman Manchu dictionary has reached Seattle
  148. Jerry Norman's Manchu dictionary has appeared
  149. Two things I am thinking about as Hacker School begins
  150. The white powder on the pages of library books
  151. Non-math uses of LaTeX
  152. Hacker School
  153. Hacker School (dojo/recruiter for programmers) begins in four days
  154. Dependencies for scipy and matplotlib not handled by pip
  155. The National Do Not Call Registry no longer works well
  156. Early evidence of a dislike of Christmas music?
  157. Plinyesque Christmas wishes to all
  158. Getting the Android GridView sample code to work
  159. A small triumph of explicitly readable code
  160. Godfrey Reggio on technology in life (2002)
  161. Max Weber: "science is the affair of an intellectual aristocracy" (1918)
  162. First day of Android coding: two problems solved
  163. Black optimism explained
  164. Talking across the pre- and post-computer border
  165. Getting used to the disappearance of old institutional models
  166. Anything less than perfect is a failing grade
  167. Recovering from hurricane Sandy
  168. Max Weber on meritocracy in academia (1918)
  169. Our state of things in New York right now (after hurricane Sandy)
  170. Max Weber on the "strange intoxication" of a passionate vocational devotion (1918)
  171. LaTeX's extract package, used for isolating the contents of environments and commands
  172. Fellini movie "Broadway Bomb" being filmed in my neighborhood
  173. Does Apple view an "iPhone" phone number as something different from a "mobile" phone number?
  174. Columbia University Libraries finally removing the card catalog
  175. One more rule of thumb for the New York subway
  176. Two further rules of thumb for the New York subway
  177. Two inches taller in two years
  178. Alternate ways to say "pop" and "push" in computer science
  179. Poulenc's Dialogues des Carmélites at the Dell' Arte Opera Ensemble
  180. Andrew Nathan on Doh Chull Shin on Confucianism and Democratization (2012)
  181. Proofreading poorly OCRed material
  182. New York State redistricting maps on line at CUNY's Center for Urban Research
  183. Karl Berry on free software (2005)
  184. The SEC on the utility of Python as a secure and accessible tool for generating official reports (2010)
  185. Hill Country
  186. Yogurt whey-starter pickled (soured) mackerel
  187. Images (figures) on facing pages in a LaTeX document
  188. Just what is being centrally limited in the "Central Limit Theorem"?
  189. Reloading modified code when using the Ipython interactive shell
  190. Alistair Cooke on H. L. Mencken's typing (1956, 1977)
  191. Jerry Norman (1936–2012)
  192. Ptisan issues
  193. Elia Kazan on the need for selfishness
  194. "Neither side took prisoners" — Japanese and American atrocities in the Pacific theater of World War II
  195. Surprise! You have a different Congressman now but no one thought you needed to know.
  196. Another notice of the bureaucratization of academia
  197. Bogusław Jackowski on "worldwide licensing madness" (2008)
  198. Accommodating the Chinese hunger for official seals on official documents.
  199. Bond Street and a story about a smartphone
  200. Another bond to Apple is lost as MobileMe Sync is discontinued
  201. Charles Ives (1874–1954) on his life in business (1933)
  202. "Taikonaut" and the new Cold War
  203. James Lang on improving understanding and retention by increasing "cognitive disfluency" (2012)
  204. Lǔ Xùn 魯迅 (1881–1936) on the truth behind Confucian morality (1918)
  205. Ray Bradbury (1920–2012) on cars (1963)
  206. Ray Bradbury (1920–2012) on success in the arts (1963)
  207. Chinatown breakfast offerings
  208. Zed Shaw on why to use C (2011)
  209. A step in my Chinese education
  210. Age and the MBA
  211. Useful Python time formats for dealing with HTTP headers
  212. An encounter with Google's security rules
  213. HTML headers for keeping track of updated webpages
  214. William Hung 洪業 (1893–1980) on Confucianism (1980)
  215. David Daniels on one's "other voice" (1998)
  216. Elia Kazan and questions of betrayal
  217. Advice on preparing herring
  218. Two limitations of call-forwarding on Google Voice
  219. Student protests in Montréal and thoughts about tuition
  220. Call-screening in Google Voice has a problem
  221. Cortlandt Alley's Chinese name
  222. Chinatown shorthand
  223. "Download statusbar" add-on for Firefox
  224. The ceremonial gateways of Montréal's Chinatown
  225. Nailset = chasse-clou
  226. Restaurant Mai Xiang Yuan [Màixiāngyuán cānguǎn 麥香園餐館] in Montréal
  227. A bon mot of Peter Carey about reviews of one's work (2012)
  228. A bon mot of Peter Carey about New York (2012)
  229. Identifying the active bridge adapter for use with a headless virtual machine on VirtualBox
  230. Doubts about l'affaire Chén Guāngchéng 陳光誠
  231. Military officers who cannot count
  232. Parallel text and vocabulary in LaTeX
  233. A stricture on Google Voice
  234. Resolving VirtualBox error VERR_INTNET_FLT_IF_NOT_FOUND
  235. Ubuntu 12.04LTS (Precise Pangolin) on VirtualBox
  236. Recordings for Classical Chinese
  237. Arthur Luehrmann on "computer literacy" (1972)
  238. The origin of the symbol Θ (big theta) in asymptotic notation
  239. Being censored in China
  240. The experience of learning vim commands
  241. How should I rate this movie on Netflix?
  242. Netflix miscalculation — Hugo
  243. Curious vim behavior: treats date range as subtraction
  244. Alexandra Lord on the myth of the academic career (2012)
  245. Elia Kazan on getting along in society (1974)
  246. ssh unavailable over Amtrak's wifi network
  247. Tricked again by Python's mutable objects
  248. Is blocking ads theft of service?
  249. A poor analogy on intellectual property rights
  250. A mutton chop at Keen's Steakhouse
  251. An anecdote about William Hung (Hóng Yè 洪業, 1893-1980)
  252. Sorting a list of Unicode strings in Python, case-insensitively and ignoring diacritics
  253. Avoid deleting the contents of a file in Python through sloppy use of "write" mode
  254. Reloading a Python module after modifying it
  255. Frank Mittelbach on documentation (2006)
  256. Frank Mittelbach on collaboration (2006)
  257. Frank Mittelbach's "moral obligation" license for the LaTeX multicol package
  258. Keith Whalen records scales and patterns from the Slonimsky Thesaurus
  259. Calligraphy in Chinatown
  260. Manchu dictionary done
  261. Bernard Shaw (1856–1950) on the damage done by immaturity in politics
  262. Gotham breakneck to Chinatown
  263. Calculus III progresses
  264. Some Western recipe-names as transformed by the Taiwanese linguistic experience
  265. Class war against the banking and financial industry
  266. Avoiding the Emailyama
  267. Adblock Plus is the most useful piece of shareware I've ever had
  268. A less painful way to install Adblock Plus filter-subscriptions in Firefox
  269. Tales from Calculus III
  270. Jack Cheng on "the technology I grew up with" (2012)
  271. Distribution of fonts: competing models are coexisting
  272. MoinMoin for notebook-wiki (and WordPress, you are trying the patience of my affections)
  273. generate native MATLAB code from finished figures, for study
  274. Quintilian on laziness and difficulty in one's studies
  275. Guide to Gwoyeu Romatzyh 國語羅馬字 (tonal spelling for Mandarin)
  276. Guide to the radicals of the traditional Chinese dictionary
  277. Origins of the Mandarin Phonetic Symbols (注音符號/ㄅㄆㄇㄈ)
  278. Installing UCC certificate for multiple domain names hosted virtually on a single server
  279. QuickTime Pro easily concatenates .m4v video files
  280. Columbia to Chinatown walk, 20120122
  281. A local custom without the corresponding exotic saying in rural Taiwan
  282. HTTPS being rejected at Yahoo hosting
  283. Classical Chinese syllabus posted; using Landslide for markdown-to-HTML5
  284. Phonosymbolism, etymology, and the nebulous Chinese word family
  285. Simple meal at Shui Mei Café (嘎嘎叫, 67A East Broadway, NYC), formerly So Go Café)
  286. Are cell phones and bananas radioactive?
  287. LaTeX and electronic documents
  288. New definition of “algorithm”
  289. Materials used in paper bank statements
  290. Finally making progress with Vim
  291. Kenneth S. Wherry on American influence in China (1940)
  292. Propagation of a meme and a metameme
  293. Against the single time zone
  294. Hamish Milne on transcriptions of Bach (2005)
  295. Choosing a suitable site for fieldwork, and working with illiterate informants in China
  296. Yuen Ren Chao (1892–1982) urging Americans to resist Chinese telephantasmia (1921)
  297. The brown German flour of Przasnysz
  298. Recollection of the traditional bagel in central Poland before World War I
  299. Vaclav Havel (1936–2011) on doing good work (1978)
  300. Vaclav Havel (1936–2011) on the "dictatorship of technology" (1978)
  301. Vaclav Havel (1936–2011) on ideological enslavement (1978)
  302. Vaclav Havel (1936–2011) on law (1978)
  303. Vaclav Havel (1936–2011) on responsibility and a "post-democratic" system (1978)
  304. Vaclav Havel (1936–2011) on "opposition" and "dissident" (1978)
  305. Vaclav Havel (1936–2011) on ideology (1978)
  306. 'Factorial' in Chinese (jiēchéng 階乘/阶乘)
  307. Leibniz’s theodicy, dynamic programming, and strategies for learning
  308. Emanuel Derman and Paul Wilmott on mathematical models and self-delusion (2009)
  309. Y. R. Chao and Henry Sheffer added to the Mathematics Genealogy Project
  310. Two more rules of thumb for the New York subway
  311. Math in the Movies
  312. Jim Coplien on reflection and problem-solving (2011)
  313. Richard Feynman on practical applications of the theory of gravitation (1964)
  314. Karl Popper on understanding a problem (1963)
  315. Galileo on "reason conquering sense" (1632)
  316. Apparent error in Python's priority queue and heapq
  317. Literacy book finally out
  318. Y. R. Chao on his dissertation (1974)
  319. Doctoral pedigrees
  320. Lack of stable sort in Python's priority queue
  321. Suitable pots for making turmeric tea
  322. Neuro-plasticity and strategies for improving cognitive functioning: "The Brain Fitness Program" (2007)
  323. Code-switching between comfortable cognitive aptitudes and the main aptitudes used in math and coding
  324. Wishes for the Orthodox Nativity Season (began 15 November this year)
  325. Two rules of thumb about transportation in New York
  326. Pípá yā 琵琶鴨 (Frisbee Duck)
  327. Testing the reliability of the Python priority queue
  328. Edsger Dijkstra on programming as an intellectual discipline (2001)
  329. Edsger Dijkstra on the name of the field Computer Science (2001)
  330. Edsger Dijkstra on anthropomorphizing computers (2001)
  331. Edsger Dijkstra on mastery of one's native tongue as a vital programming skill (2001)
  332. Edsger Dijkstra on the origin of his shortest path algorithm (2001)
  333. Efrem Podgaits's New York Mass (2001)
  334. Anecdotal report on experimenting with creatine as a study aid
  335. "Suppose" for math proofs, in LaTeX
  336. A rule of thumb in teaching
  337. Graphing flowcharts and automata in LaTeX
  338. Perception of time and suspension of finality (studying math)
  339. Suddenly perceiving the cantus firmus in a Bach chorus
  340. Two of Elvira's arias from Don Giovanni
  341. Identifying robots among human beings
  342. Apparent misspelling in LaTeX command set: \guillemotleft and \guillemotright
  343. Table of contents in a LaTeX book: make the TOC entry different from the actual chapter headings in the text
  344. Competition and sharing in academia
  345. Kuhn and Popper
  346. Herb Gross's calculus lectures
  347. The abbreviation UTC as an acronym
  348. Clyde Haberman on validating one's authenticity as a New Yorker (2011)
  349. The era of lost words
  350. Never odd or even
  351. William Deresiewicz on multitasking and solitude (2009)
  352. Bjarne Stroustrup's advice to up-and-coming programmers (2008)
  353. Chet Ramey's advice to up-and-coming programmers (2008)
  354. Bjarne Stroustrup on the name C++ and common criticisms of the language
  355. Steve Bourne, advice to up-and-coming programmers (2009)
  356. Alfred Aho on the origins of awk (2008)
  357. Leslie Lamport on thinking first and on commenting code (2007)
  358. Pens of choice for linguistic fieldwork
  359. How I learned LaTeX
  360. Some bons mots from Edsger Dijkstra (1984)
  361. Non-paean to Steve Jobs
  362. Annotations of Cormen et al.'s algorithm for a Red-Black Tree (delete and delete-fixup functions only)
  363. John McCarthy on "Generality in Artificial Intelligence" (1987)
  364. Brian Kernighan's summary thoughts on scripting languages
  365. Changes to the inventory of IPython magic commands (v. 0.10 to 0.11)
  366. One man's calm reflection on Java-think in Python
  367. mdfind as a substitute for locate on Mac OS X
  368. Reconsider P. T. Barnum's reputation
  369. LaTeX macro for circling answers on math problem sets
  370. View of the Mariana Trench
  371. Simulating private variables in Python
  372. Choice of formats for basic code documentation
  373. Dennis Ritchie on Computer Science and Commerce (1984)
  374. Inconsistent results of the same seed in random.seed() on different Python installations
  375. An opinion on vi configuration
  376. The virtue of Vim (or: why I do not remap copy and paste)
  377. Shark fin and the economics of Chinese "face"
  378. Two funerary practices and the end of a good story
  379. An important skill for instructors
  380. p::c
  381. Twice-a-day mail delivery
  382. Portmanteau characters in Chinese (abstract)
  383. A math professor I enjoyed
  384. The state of my Netflix patronage
  385. Longevity vs. versatility of code
  386. A new kind of noise in the subway
  387. Router VI is dead
  388. Tinker Tailor remake
  389. Automated upward pricing spiral
  390. Break-in?
  391. Telephantasmia, one of the great gifts of Chinese culture
  392. September 11th sensations
  393. Whether to take a small loss or consent to the devaluation of the US dollar
  394. City checkpoint chaos
  395. Continuing opportunity for techno-elitism
  396. A worry of Donald Knuth's
  397. An opinion of TeX
  398. Advice on teaching English in China if you lack a TEFL degree
  399. "The Highline" Park
  400. Plutarch on the sensitivity and versatility of the human mind
  401. Plutarch's praise of the "fox" temperament
  402. Unagi hitsumabushi 鰻櫃まぶし
  403. My mother and me, at work on the Early China index, 20110526
  404. juémíngzǐ 決明子 tisane
  405. Brillat-Savarin on the pleasures of the fast
  406. University of Maryland, (College Park) general education rated D in a national survey
  407. The EMACS meta key and the standing desk
  408. A rule of thumb in choosing one's tools
  409. Dr. Johnson on the "fox" temperament
  410. Carl Elliott reviews Ginsberg, Fall of the Faculty (WSJ)
  411. Hard copy vs. electronic copy
  412. Deborah Ball's article on the opposition to standardizing the Romansh language (WSJ)
  413. Boris Veytsman's review of Kottwitz, LaTeX Beginner's Guide
  414. Why even 212 phone numbers calling in-area have to dial 212 first
  415. Dr. Johnson on keeping a diary
  416. Against object-oriented design (except in scripting languages)
  417. Worrying about inadequate memory to hold program and debugger (1973)
  418. Consequences of a compiler defect
  419. The Internet and scripting languages
  420. Newton's own suffering at math
  421. Fresh turmeric-root tea
  422. Appreciation of awk
  423. "Computer Science, Modern Languages Most Gender-Polarized Majors"
  424. Food issues during the Siege of Leningrad
  425. Starting a blog