Impression from NYC and the RC

Two months ago I was on a train going from Montreal to New York City. It’s a long ride, but I used the time on the train to triage all the coding project ideas I could work on while at the Recurse Center (RC). So many projects; so many ideas.

Today I’m on the same train heading back to Montreal and have another 10 hours to triage the thoughts, experiences, and observations about the big city and the social experiment that is RC. Here is my best shot at it—stream-of-consciousness-style—before I forget it all.

New York City

The past two months have all been a blur. From the day of arrival when I tried to enter the wrong apartment, to the first contact with NYC street noise insanity outside of my window, to the snow storm, and all sorts of good foods. I’m very impressed with the city, but I’m not in love. Here are my observations.

New York is a big city. Compared to Montreal, it’s as if someone copy-pasted 10x the city. Or perhaps the better computer analogy is someone filling a map with the “bucket-fill” tool and completely forgetting to stop. Seriously, it seems like there is waaaay too much shopping areas with high-fashion and luxury brands. Do people really need to do so much shopping? I don’t mean to be judgmental, but as someone who is ideologically against consumerism, I felt like I was totally in the wrong place.

The energy of the city is amazing. It seems everyone is getting things done, shipping products, or otherwise being creatively on top of their game. Now I realize it is impossible for everyone to be successful, but people certainly carry themselves as if they’re crushing it. Most people I talked to made a good impression on me. They’re proud of what they do, confident, but not overly full of themselves. New Yorkers are actually interested in hearing you out, and seeing what you have to say. I felt very little closed-mindedness and little-mindedness from the locals, which is great.

I really like the demographics of the city. Everywhere I went, there are young people: from school kids who talk like adults, to the well-represented university crowd, through the numerous artists, to the middle-aged professionals contingent, and also older people who still keep in shape. Everyone is well dressed and good looking. At times I felt as if there is some sort of giant “face control” department at NYC ports and train stations that does not allow non-good-looking people to come to the city (How did I get in?).

I’m used to “measuring my words” when meeting new people in order not to alienate my interlocutors by mentioning math, quantum physics, or computer topics. When touching on such topics, I use an interactive approach to “feel out” the level of comfort of the person I’m talking with and judge how far I can go with this topic of conversation. The last thing you want is to jabber endlessly about a technical topic to someone not interested in tech, or to talk about math with a person who has a math phobia. Talking with people in NYC, I was pleasantly surprised to realize I don’t need to measure my words all that much. I would hit people with the full geekfest, computer jargon, and even quantum topics and they would handle it just fine. People are more knowledgeable than you think, and those that don’t know anything about the subject matter are willing to go into it and still had interesting things to say. That’s really nice. It’s great to be around people who can handle the tech talk and the science talk. All the New Yorkers I spoke with are smart, open minded, and generally well aware of the world.

The New York lifestyle is definitely something I could get used to. Two months of living there is not enough to get used to it or see enough of it to be a judge, but I met enough locals and saw enough to get a general feeling for what it’s like. First you need a NYC job. That’s a key thing if you are to enjoy the \$8 pints, \$15 cocktails, and \$30+ entrees. I mean anyone can afford to eat out once in a while, but if you’re not making 100K+ in this city, you’ll have a lot less opportunity to enjoy all the restaurants and bars. All these places of socialization are waiting for you after work. Unlike the dwellers of most North American cities, New Yorkers tend to go out after work. Whether it’s for a fancy dinner, or a quick dinner, or for straight-up alcoholism activities, people don’t want to go home. The city is very European in that way. You get to talk to people, see your friends, and generally hang out rather than go home. I like that very much.

The noise though. Oh. My. Fuckin’. God. The noise is terrible. It seems like every person who brings a car into Manhattan wants to exercise their right to use the klaxon as much as possible. Seriously, if the street is jam-packed for hundreds of meters ahead of you, will honking really make a difference? It’s not just the honking though, the constant presence of people at all hours with their need to scream, the large open spaces that carry sound, the delivery trucks, the construction work, the garbage collection trucks, and the highways. I am generally not affected by noise, but I never thought it can be this intense. In fact, I read that some people can get used to the noise level and need it for creative stimulation.

But it’s not just New Yorkers in cars that like to signal. Everyone in NYC is big on signalling. There are a lot of expensive bars and restaurants where the locals can feel special because of the hefty bills they will pay, but I guess it’s like that everywhere around the world. The specific signals New Yorkers use to show their higher status relate to the most difficult things to have in the city: cars and dogs. Owning a car in Manhattan must be an absolute nightmare with all the traffic and how difficult it must be to find parking. For this reason, if you’re seen rolling down the street in a fancy convertible, then you really must be something special. It’s a bit like high-heels—they’re attractive because they’re totally impractical. It seems it’s the same with owning a dog in NYC. We’re talking about a stone and concrete jungle with very little green areas. Why do you have a dog? Where are you going to take it out for a walk? Still, if you own a dog in these difficult conditions, then you must represent. Anyway, human nature is weird.

The Recurse Center

My six weeks at the Recurse Center were very much what I expected them to be, but also very surprising and inspirational at the same time. I kind of knew what to expect when going into RC from talking with people who’ve attended: RC is a shared office space with a focus on coding projects and exploration. This description is accurate, but completely fails to account for the amazing people that are present in that shared office space. Imagine co-workers that you actually want to talk to? How cool is that?

I’m in total awe with the people that I met. There were extremely knowledgeable people with very interesting background and achievements, but also inspiring “junior” people with insane ability to learn quickly. We had people who know how to use nearly every imaginable programming language: Agda, Clojure, Coq, C, C++, Erlang, Go, Java, JavaScript, PROLOG, Python, and even COBOL. How often would you have access to  such variety of people and be able to ask questions of them, or just “Hello Joe, can you give me an intro to PROLOG?”

I definitely felt some impostor syndrome after meeting all the people and hearing about the projects they were working on, but then I stopped comparing myself to everyone and it was OK after that.

The main idea for the Recurse Center is to provide the learning environment but not impose any structure. The first day has a lot of “official” events organized with the goal of getting people to know each other, but apart from that we’re left pretty much on our own to figure out what we want to do. People organize events, form reading groups, and work on projects in pairs or larger groups.

The first week was a bit strange and anti-social. I would show up in the early morning and work on some coding projects, try to socialize over lunch, then back to more coding in the afternoon, then go home. No beer or after-work pub activity. I think the people in the Spring 1 batch were realizing they are halfway done with their batch and trying to be more productive and the new Spring 2 people were not going to suddenly start talking to each other and making friends. Everyone felt distant, busy, and not wanting to be disturbed until the first Thursday game night. This evening was a marked change, at least for me, since after a few beers I felt much more comfortable talking with people. Beer is the universal ice breaker. After this first social event, I felt much more comfortable talking to people, joining conversations, and generally interacting with people. As if somehow drinking a few beers in the same room had turned us from coworkers into buddies.

Throughout my time at RC there was a constant tension between working on projects and socializing. My original plan was to push forward on one project, or another, until it is in a shape where it can be shown and shared with others. Needless to say this never happened, since “cleaning up” the projects and getting them into “not ashamed of the code” state was too much work, and would have required much more time than a half-batch. Once I realized this, I said “fuck my projects” and decided to focus more on talking to people, sometimes helping with whatever they’re working on, sometimes teaching math, doing Django demos, explaining pointers in C, and generally trying to be useful as a teacher. At the same time I played the student role in several other contexts where people more knowledgeable than me introduced me to PROLOG, Neural Networks, and Formal Type systems.

Something that I realized near the end of the batch is that RC puts a lot of emphasis on not imposing any formal structure to the learning process. There are no instructors. There are no classes. There is no set curriculum for people to follow.

Not adhering to any strict procedure, formula, method, or curriculum is a very powerful idea. It makes me think of Alfred N. Whitehead’s essay titled The Aims of Education in which he warns about the danger of inert ideas. Every now and then powerful new ideas and ways of thinking erupt on the intellectual scene and overturn old and established ideas. Slowly over time the new ideas become codified and structured until they become the new dogma. Whitehead warns us that the seemingly “efficient” approaches where students are taught to “skip ahead” and directly memorize useful facts might not be the best way forward if we want truly developed learners. Instead of memorizing thousands of facts, Whitehead advocates exposing students to a few important ideas and letting them apply these ideas in various practical scenarios.

I find RC’s structure-less approach very interesting because it is diametrically opposite to my thinking about education. The power of this unstructured approach is that it will never degenerate into dogma, rote learning, or formulaic explanations. By sticking to meta-learning techniques like study groups, reading groups, pair programming, weekly meetings, and activities, RCs learning will stay evergreen. I imagine the the 2014 web study group were about Backbone.js and the 2017 it’s all about React.js. RC never becomes outdated.

At the same time I believe that some structure could be very useful for beginners. How much time was wasted by each person to setup their basic coding environment? How much time is wasted learning from the wrong source? How can beginners know which tutorial is good and which tutorial is bad? The whole assumption of putting learners in charge of their learning process assumes that learners are adults and have well-developed meta-cognitive skills. It just so happens that all the people at RC are very smart and capable of “taking ownership” of their learning process so it works out, but I’m still left thinking that some structure could be introduced into RC without losing the flexibility.

 

Possible improvements

I thought of a number of ideas which would have made my experience better at RC and which could benefit people who are learning to code in general.

  • More short-term, throwaway code projects. I think I wasted a lot of time thinking of the projects that are good, worthwhile, or of general interest. I felt I need to come up with a really good idea for a coding project if I’m going to invite others to collaborate with me. From what I heard around me, many people were working on quite serious, long-term projects (think three week-long projects, or six-week long reading group). Those are cool and you’ll learn a lot in the end, but I think short, throwaway projects are much more valuable for learning. I had a lot of fun working on half-day projects in collaboration with people. If I come back to RC, I would focus 70% on such projects: get technology A to work, install B on top of C, wrap D inside and E environment, write a hello world in F then package your code and make it run in the G cloud. All of these activities would take an expert 30 minutes to do. A solo beginner would take 5-12 hours, and a team of beginners 3-5 hours. All the boring scary parts of getting things off the ground are so much better when you’re working in a team.
  • At the same time I think it’s good for everyone at RC to have one long term “show off” project to work on, dig in, and become sort of expert at. This could also be a collaborative project, it doesn’t need to be a “my portfolio” project, but I think it’s important for everyone to learn how to polish the code beyond the “school project” level. It would be great to have the full end-to-end experience from idea, design, implementation, coding enough to make the app useful to end users, deploy the code in a production environment, writing tests, etc. It doesn’t make sense to do all these extra steps for each of the throwaway projects, but it totally makes sense to go through the motions at least once for one project.
  • Code reviews. We had a great conversation over lunch with A., B., and N. where we all agreed that we somehow need to introduce the notion of code reviews and collaboration best practices (releases, feature branches, pull requests). It doesn’t make sense to do code review on the throwaway projects, but I think everyone would benefit from code review on their “show off” project. Imagine pairing a Python beginner and a Python expert on a simple web app project. Using only one hour per week of productive time, the Python expert could transfer all the best practices about conventions, code organization, idiomatic Python, testing tools, and deployment to the beginner.
  • Starter tutorials and curated learning resources. This is basically what I was working on throughout most of my batch. Imagine a collection of links to learning resources about every imaginable computer-related topic and each topic comes with a short tutorial prepared by a recurser that gives you the “hello world” introduction to the topic. I think this sort of curated list of links to resources, if continuously updated, can really improve the life of beginners. Instead of trusting “uncle google” to find the most relevant tutorial on topic X, you can go to a trusted source and get started learning topic X without the fear you’re missing out on some better tutorial somewhere else. Perhaps the page on topic X could use the Socratic method and just ask questions? For example, the page on JavaScript could ask: What is this? What is a prototype? What is the difference between == and ===? And other questions that will lead learners to seek answers on their own.

I think the above four ideas would really improve the RC experience for future attendees. I personally feel I wasted a lot of time in the first weeks thinking of a grandiose project to work on, and in retrospective I wish I had worked on smaller half-day, or one-day projects to learn as much as possible. I think mini-projects lend themselves better to collaboration. Imagine someone asks you to collaborate on a week-long project to do some big thing, versus someone asks you to collaborate on a small toy project for half a day?

Conclusion

Overall my stay at RC and in NYC was a good experience. I learned a lot. I got out of my Montreal routine/bubble. Above all, I met some amazing people. Fuck computers and coding resources… people are the best resource of them all! Many thanks to the RC Staff, Spring 1 and 2 batchmates, and all the alumni. Hope to see y’all again.

Linear algebra final push

Last week was a watershed moment for the linear algebra book. My editor finished her final pass of edits to the text and passed the ball back to me for the final touches. All the remaining tasks have been placed in a Trello board and now all I have to do is act on them to finally get the job finished.

It’s difficult to describe in words what a relief finishing this book will be for me. This book has been my life for the past four years. Here is a time lapse video that shows two-years-worth of commits in two minutes.

I want to thank all the readers who have supported me throughout the years. Thanks for all the feedback and suggestions, which made the book better. A big thank you to all the gumroad readers for your financial support and your patience—I’ve been “finishing up” the applications chapters for three years, yet not a single reader has threatened to come and break my legs because of the delays. Y’all are awesome!

 

 

Request for feedback

In parallel with the edits of the linear algebra book, I’ve also been working on a new look for the book covers.

Which version do you prefer and why? You can reply via the comments below or send me an email.

Linear algebra problem sets progress

I’ve been working on the problem sets for the linear algebra book non-stop for the past month. It’s a lot of work, but also very rewarding. I’m going through online resources and looking for inspiration by reading exams and books to find illustrative exercises and challenging problems. This leads to a lot of  learning and reviewing of ideas along the way…

Finalizing 50 pages of problems and solutions is not an easy task, luckily I have good coffee to temporarily boost me, and more importantly access to the SymPy live shell. In combination with TeXShop, writing up more than one solution per hour becomes possible.  Check this screenshot if you want to see the author at work . Using bit.ly as a URL shortener, you can put an entire problem solution as a URL: http://bit.ly/distxrcis.

So far I am yet to find a useful linear algebra problem that I haven’t covered in the book. I’m pretty happy about this because when writing a textbook from scratch you never know what topics you might miss. I’m only using the formulas from the book, and able to handle most problem types… Linear algebra? we got you covered!

Call for student assistance: are you taking a linear algebra class this term? Do you want to solve all the exercises and problems in the book as “extra practice” for your final exam? Get in touch with me ASAP (my_first_name at minireference dot com), and I’ll send you the PDF of the entire problem sets. It might take you up to a week to go through all of them, but by the end of it you’ll be able to handle even the toughest  linear algebra final.

No BS math and physics v5.1 update

Over the last years, several readers uncovered mistakes in the No bullshit guide to math & physics, which I immediately fixed in the source. The errors were mostly minor, so they didn’t warrant a new edition, but once I reached a threshold of six errata, I decided it’s time to release a v5.1 update. With this bugfix update, I took the time to make some other minor improvements described below.

Errata

Most of the mistakes in v5 of the book were in the exercises and problems. I’m happy to announce there are no major conceptual problems, or mistakes in any of the core equations. Here are the mistakes in v5.0 (Aug 2014) of the book:

  • P1.41: Both calculations should use the radius instead of the diameter. The change in height is $h_2 – h_1 = 5.47 – 4.41 = 1.06$ cm.
  • P1.44: Answer should be 8.42m = $4\sin 40 + \frac{1}{4}(2\pi(0.5)) + 4\cos 40 + 2$.
  • P1.47: Answer should be 180 degrees – 40 degrees = 140 degrees.
  • P1.51: Question describes the water tank as $12 \times 6 \times 3$, but solution uses $12 \times 6 \times 5$. The question was changed to match the existing solution: the tank now has height $5$[m].
  • P2.9 part (3) $v_f$ should be 6 [m/s], not 10 [m/s].
  • P2.10, part 4. Distance should be 13[m] not 14[m].
  • page 202: Revolution of the Earth example: $v_t$ should be 328.32 m/s not 464.32 m/s, giving a final answer of 1181.95km/h not 1671.56 km/h.
  • 5.5 Limit formulas, page 264 at the bottom: removed formulas $\lim_{x\rightarrow0}\frac{\ln(x+a)}{x}=a$ and $\lim_{x\rightarrow0}\left(a^{1/x}-1\right)=\ln(a)$. First formula is wrong, second is not useful.
  • page 286: “Consider the point $P=(x_P,y_P)$ that lies on the circle $x^2+y^2=R$.” should be “Consider the point $P=(x_P,y_P)$ that lies on the circle $x^2+y^2=R^2$.”
  • page 401: the correct conversion formula for inch is 1[in] = 2.54[cm] and not 1[T] = 1000[kg].

 

New math exercises

Several readers complained about the math fundamentals chapter being too “rough” for complete beginners. To fix this, I did a critical rereading of the material and corrected some mistakes of continuity (there was crazy rough patch in Section 1.2 where I suddenly jump into negative and fractional exponents that—not surprisingly—some readers found confusing). I also interspersed exercises throughout Chapter 1 so readers can now test their understanding as they progress through the chapter.

 

Index

Thanks to the suggestion in a comment on amazon, I decided it the book should have an index. It turned out creating an index was a very time-consuming task, but it was very totally worth it since it allowed me to standardize certain terminology (e.g. function range vs function image) and weed out certain inconsistencies.  The exercise of cataloguing every concept used in the book will help with STRUCTURE project too.

 

New proof of the chain rule for derivatives

A mathematician friend of mine pointed out a mistake in the proof of the chain rule for derivatives in the book. The hand-wavy argument that I had improvised had possible divide by zero error: the quantity $\Delta = g(x+\delta) – g(x)$ can be zero, so it’s not OK to use it in expressions where it appears in the denominator. In other words, bullshit had creeped into the book!  We can’t have any of that in a book which claims to be bullshit free! The new proof of the chain rule for derivatives is longer and more technical, but at least it’s not wrong. Hopefully I will not alienate my readers too much by having such a technical argument in the middle of the calculus chapter, but there really wasn’t any way to make the proof simpler or more intuitive. It’s just a technical argument.

 

More calculus problems

Upon critical review, I found the section on surface and volumes of revolution was a little short. Sure all the formulas are introduced, but it would have been a stretch to assume the average reader will be able to pick up the concepts from these few pages. To remedy this, I added a few more pictures, beefed up the discussion, and added some problems. I also came up with a “append only” policy for adding problems to the book—this way the numbers won’t change between versions so if  a prof assigns P5.33 to their students, it will be the same problem in v5, v6, or whenever. The new problems added test the student’s ability to apply the volume of revolution formulas and also the infinite Riemann sum formula.

 

The diff

As with previous updates, I’ve generated a red-blue diff of all the changes between v5.0 (Aug 2014) and v5.1 (July 2016). You can check out the diff to see the details of all that changed.

 

Right now I’m waiting for the green light from my editor about the changes and the next step will be to push the updated PDFs to all distribution channels. I’ll also send out an update email to all readers.

Git for authors

Using version control is very useful for storing text documents like papers and books. It’s amazing how easy it is to track changes to documents, and communicate these changes with other authors. In my career as a researcher, I’ve had the chance to initiate many colleagues to the use of mercurial and git for storing paper manuscripts. Also, when working on my math books, I’ve had the fortune to work with an editor who understands version control and performed her edits directly to the books’ source repo. This blog post is a brainstorming session on the what a git user interface specific to author’s needs could look like.

The other day I was onboarding a new author and had a chance to explain to him the basics of git, and I realized how complicated the action verbs are. To save some work, you need to put files in the staging area using git add <filename>, commit the change to the local repo, then push the changes to the remote repo. These commands, and the corresponding commands for pulling changes from the remote repo to your local one, and updating your working directory from the local repo, are very logical after you get used to them, and represent necessary complexity. The diagram below illustrates well the different git verbs newcomers to git need to get used to.

git verbs explained

(Credit: Kieran Healy‘s excellent guide to git)

 

So what would git for authors look like?

It’s my non-expert opinion that this is too much complexity for the average non-technical person. Imagine a teacher who wants to use an OER textbook with her students, and in the process of producing the document for her class she finds some typos, which she wants to contribute back to the OER textbook project. Let’s do a thought experiment and imagine a humane interface that would make sense for this task. To make the thought experiment more concrete, we’ll personify the teacher as Jane,  a university professor who is in charge of a first-year physics class.

We’ll assume github is used as the storage backend, but most of author’s OER browsing,  and collaboration happens on a different site (say ezOER.com) whose users are authors, teachers, students, and parents. Suppose the OER book that Jane wants to use is College Phyisics by OpenStax, and this book is available in “source” format from the github repo openstax/physics, which we’ll refer to as upstream below. Given this preexisting setup, here are the steps the teacher would use:

  1. Login to ezOER.com
  2. Copy openstax/physics  to janesmith/physicsbook  (note we don’t say “fork” because it has different connotation as to the permanence and authority of the repo)
  3. Clone janesmith/physicsbook to her ~/Documents/School/Textbooks/OpenStaxPhysics
  4. Follow instructions for “building” the book locally. (e.g. running pdflatex three times)
  5. Performs customization like:
    1. Change cover page
    2. Remove chapters she doesn’t plan on covering in her class
    3. Add a custom preface with references specific to her class
    4. Choose values for “configuration variables” like font size, paper size, etc.
  6. Generate custom book for her class (PDF for print, PDF for screen, .epub, and .mobi)

At this point, she can distribute the eBooks to her students using her school’s LMS’ “file uploads” feature and setup the print PDF for print-on-demand using lulu.com, so students will be able to order the book in print. Her students will benefit from a world-class textbook for $20-30 when printed as a two-tome softcover, black-and-white print book. No payment or further engagement with ezOER.com would be required.

If she doesn’t like her school’s LMS system she could “host” her custom book on ezOER.com. These are the steps she would take to publish her changes to her public-copy repository ezOER.com/janesmith/physicsbook:

  1. git save: combines the effect of git add and git commit using a two-prompt wizard
  2. git publish

She could now give the links to the “build” directory of ezOER.com/janesmith/physicsbook.

Now suppose that halfway through the course, she finds some typos in Chapter 2 of the book, which she wants to correct, and furthermore she wants to share her corrections with the “upstream” copy of the textbook. (Bear with me with this scenario, we’ll have to think more about good incentives to share your corrections with others, but for the purpose of this thought experiment let’s assume Jane is feeling altruistic today). These are the commands she’ll have to use to “suggest edits” to the upstream authors who manage openstax/physics:

  1. Make the corrections in her working directory
  2. git save
  3. git publish (to her copy)
  4. git suggestedits which pops up a wizard asking her to give a short label for her edit suggestions, and pick the commits that should be part of the “suggested edit” (a pull request behind the scenes). The suggestedits command will perform the following steps behind the scenes.
    git checkout -b typoFixesChapter2
    git rebase -i   (choosing only corrections commits, and not the customization commits)
    – open github pull request

To keep things simple, Jane will never be shown the typoFixesChapter2 branch, and for all intents and purposes the rest of the workflow will be done entirely through the ezOER.com web interface. For example, if the upstream maintainers wants her to change something in her “suggested edits” (pull request), she’ll have to make these changes through the web interface, rather than edit the branch typoFixesChapter2 and push again. For all intents and purposes, Jane is always working on the master branch of her copy of the book.

I think introducing the new verbs save, publish, and suggestedits would be easier to use and correspond more closely to authors’ needs.

More power tools for authors

Assuming the source format is text based, git’s basic diff functionality will prove to be useful for “watching” changes made to large collections of text.  If the source is LaTeX documents, ezOER could run latex-diff to generate diff documents showing “rendered” differences between revisions, also know as red-blue diffs.

The build process could be automated using a generic continuous integration server. A script could run after each commit to regenerate the book in various PDF and eBook formats, and also generate diffs. We could even have some “language checks” scripts, that act like linters for text.


 

I’ve thought about this previously, but now the “authoring workflow” is becoming clearer. I need something like this for managing Minireference Co.’s (closed-source) content, but I plan to build all the tooling as open source. Would love to hear you feedback about this idea in the comments below.