Archive for July, 2017

Week 9 at an Unbootcamp

Thursday, July 20th, 2017

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.

Week 8 at an Unbootcamp

Thursday, July 6th, 2017

First ordinary week under the new model

As reported in my previous post, Learners Guild in Oakland, California, recently made a major change in its software-development curriculum. The week ending on 23 June was a special week: All 120 Learners got evaluated for “sorting” into 5 “phases”.

I interviewed for phase 3, and was placed, as expected, into phase 2. Results varied greatly among Learners, but the theme was conservatism, with doubts resolved in favor of placement into earlier phases. As a result, phases 1 and 2 are now the largest, accounting for about 70 Learners.

The week ending on 30 June was the first ordinary week of the new model’s implementation. For most of us its main novelty may be its solitary study mode. We work through the curriculum in whatever order we want, at a pace of our choosing, one by one. This affects Learners differently. I think I’m thriving under it, continually absorbing what I need to know, because if I already know something I can skip it or review it briefly to confirm, and I can slow down to master a topic that seems crucial, without needing to reach agreement with a teammate. Some other Learners have voiced deprivation of the social aspect of their work, but most have voted to keep working alone when asked about a more collective interlude.

The other main difference I notice is in the quality and detail of expert support. The old model’s emphasis on near-peer coaching gave us ready access to more advanced Learners for help and reviews of our work. The new model gives us routine access to Software Engineering Practitioners (SEPs), members of the Guild’s staff with years of industry experience. The difference is unmistakable. I have requested and received 2 code reviews, and the comments by the SEP were much more expert than I had received from any prior coach. We can also attend lectures and office hours conducted by SEPs.

While proceeding through the curriculum, we may also easily contribute to it, by proposing editorial changes, ranging from typographic to substantive. I have made several such proposals, which the SEP staff has integrated into the working documentation.

For now I have decided to work through the curriculum in the recommended order, checking off claimed skills as I proceed. I’m reminded every day of phase-2 topics that I had never studied, had only superficial knowledge of, or had forgotten. While some say they want to quickly plug their knowledge holes and interview out of phase 2 in 2 or 3 weeks, I feel no such motivation. This is the fundamental stuff. It seems like a luxury to have time to study it in more depth than I have done before. A couple of examples:

  • One enters hundreds of commands as one works in a terminal. I hadn’t learned that one can find a previous command by typing control-r and then any part of the command. The terminal interfaces (such as bash) are sophisticated programming languages of their own, with many such time-saving features. The curriculum selects some of the most useful and says “learn these”, and some turn out to be techniques that would have been worth learning long ago.
  • Using JavaScript well requires internalizing new models of time, process, event, and agent management. I grew up writing computer-driven, sequential programs. They would do something and wait for the user to do something in response, then react to that. Now I’m learning to conceptualize the interactions differently, to accommodate situations in which multiple computers, multiple users, and multiple natural processes do spontaneous things and respond to one another’s actions. When I started programming, the computer’s and the user’s actions were textual. My programs would not know what a user was doing until and unless the user pressed an enter or return key to “submit” a response. Now I need to learn how to create systems in which actions can also be aural, graphic, and kinetic, and can vary continuously in addition to being discrete. I can, for example, write a program that changes what it does whenever the user slides a mouse in a particular direction or at a particular speed, an action that would have been invisible to my programs of yore. In the old days I thought of my programs as “running” on a “computer” and being “used” in a terminal or browser. Now I need to think of the server and the client as partner agents in implementing my code. I have to decide, step by step, whether it makes more sense for the server to do something or have the client (terminal, browser, mobile phone, etc.) do it.

Such changes in cognitive models of the computing universe are implicit in phase 2, at least for me, and it seems foolish to try to rush such a re-education. I want to keep putting this panoply of new tools and concepts to use until the alien becomes natural. Week by week, the Guild’s curriculum and staff are brainwashing me, it’s working, and it’s good.