Week 9 at an Unbootcamp

Second week under the new model

I’ve been reporting in this blog on life at Learners Guild in Oakland, California, a place where an experiment in a new model of deep, holistic, inclusive, and risk-shifting software-developer training is taking place.

To its credit, the Guild is willing to make major changes in its learning model, and it did that recently, as I reported in the previous entries. My 9th week at the Guild, ending on 7 July, was my 2nd week working under the new model, in what is called “phase 2”.

I’m writing this on 20 July, and that’s 13 days later. If you are like me, you have almost no idea what you did so long ago. What’s worse, whatever you learned to do 13 days ago you no longer remember how to do. Blog now, or forever lose your past. And even that won’t retain your know-how. If you think this is one geezer’s problem, no. “Retention” is a major topic of discussion among the mostly 20–40-year-old Learners here and their Learning Facilitators. That’s because retention (i.e. non-retention) is a problem for almost all of us. In that respect, I’m not an outlier.

But don’t give up quite yet. Now, thanks to this Guild that I’m blogging about, my life is being recorded more or less indelibly, every few hours or even minutes. Well, not my entire life, but the part that matters most, namely my progress in mastering the fundamentals of JavaScript programming.

Here’s how. We are not just reading, watching, and listening in order to learn. We are also coding. It’s the only way to know whether we are learning. And coding means screwing up, almost all the time. That, in turn, means revising code in order to make it stop crashing or misbehaving. And the revisions are more often bad ones than good ones, so we want to be able to unrevise at any time. Not to mention that, if we are coding with somebody else, we need a procedure for proposing, accepting, rejecting, incorporating, modifying, and undoing contributions to our joint code.

This batch of needs has given rise to a core discipline that is drilled into us here, namely frequently updating both the local and the remote repositories that contain our code. We do this at the Guild by using the git protocol, enhanced by a web-based platform offering developer-friendly options for reviewing our code and its history. Several times a day, or even several times an hour, we are “committing” our code changes to our local repositories and then “pushing” them to the remote copies.

As a result, I can now visit my site at Github and click on a day in history, and I’ll get a list of the contributions I made that day. I can then click on any of them to see details, down to the specific changes I made on specific lines of specific files.

In fact, you can do this, too, because my site is public.

So, this might mean that blogging is unnecessary, because my every mistake and correction thereof is now a matter of public record. I leave that judgment to you.

That Github history tells me that I devoted the week partly to finishing my quest for a grasp of how the programmer can control not only what happens, but also when. In JavaScript, this is more complex than in some other languages, because you don’t merely tell your program to go to sleep for 5 seconds before doing the next thing. Instead, you tell it to come back and do something in 5 seconds but do something else in the meantime. Managing multiple flows of interacting events requires a lot of what-if thinking and testing by people who are good at breaking things.

Github also tells me I spent much of the week working on a program that manages a toy to-do list. You can use it to add items to the list, declare them finished and therefore get them removed, display the list, and other things. There is an easy way to do this, but the specifications ordered us to do it the hard way instead. The hard way uses “asynchronous” functions, which start something happening and then let the program go on to the next step. So, if I tell the program to add an item to the list, the program needs to read the list from a file, create a copy of the list in its memory, add my item to its in-memory copy, and then write the revised copy back into the file. I must do this so that the reading is finished before the content is analyzed and expanded, even though the program, in general, keeps on running after it orders the file to be read. This exercise is aimed at giving us practice in managing events when using asynchronous functions. For me, this was major thought reform, and it took a few days before I made it my own. I say a “few days”, although the week in question was officially only 3 days long, since 3 and 4 July were Guild holidays.

My reliance on Github (like others’ reliance on Facebook histories) may make my memory atrophy even more, if Socrates was right that “they will not practice using their memory because they will put their trust in writing”. But in fact I am internalizing some skills. They are mostly those that I practice often until they become idioms for me. I have also noticed for decades, as you probably have, too, that it is foolish to rely on written notes, because they get lost, become unintelligible, and become hard to rediscover when needed. But code is not notes. Code is writing that actually does work and, once it has been pruned of its errors, keeps on doing it right. We are learning how to write code that is lucid, reusable in multiple situations, and available to anybody in the world to use for free. That’s a far cry from my scribbled course notes, whose most valuable function after being committed to paper has probably been to dry hands as recycled paper towels.

2 Responses to “Week 9 at an Unbootcamp”

  1. Robert N. says:

    Thank you for writing this, as a future Learners Guild attende I enjoy seeing what will be done/can be done.

  2. Jack Sawyer says:

    You’re onto something, Jonathan. Thanks for keeping me posted. Best wishes. –Jack

Leave a Reply