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 x̂ 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]