Archive for the ‘1. Work’ Category

Week 13 at an Unbootcamp

Monday, August 14th, 2017

The basics

During my first dozen weeks as a beginning student of software engineering at Learners Guild, I had considerable discretion in selecting topics. I used that discretion to emphasize the “fundamentals” of web technologies: HTTP, HTML, CSS, and JavaScript, one by one. This was by choice, and it was also consistent with the Guild’s recent curricular reorganization, in which new Learners are gently steered toward fundamentals for the first 12–18 weeks of their study.

This means I forewent some opportunities to work on the many related technologies that tie these fundamentals together and power complex real-world applications. Instead, I strove to assimilate basic truths.

Truths such as: ['x', 'y', 'z'] is not equal to ['x', 'y', 'z'].

That’s right. They are not equal. You see, ['x', 'y', 'z'] is an “object” containing 3 properties, named 0, 1, and 2. 0 has the value 'x', 1 has the value 'y', and 2 has the value 'z'. Why, then, are the above expressions not equal? They sure look equal. Here’s why: The mere act of putting the expression ['x', 'y', 'z'] into one’s code causes JavaScript to create an object containing those 3 properties with those 3 values. But, if I ask JavaScript whether the objects represented by those two expressions are equal, I am putting them both into my code, since that’s how to ask it that question. I ask: ['x', 'y', 'z'] === ['x', 'y', 'z'], and JavaScript dutifully creates the 2 objects in order to process my statement. Since it has created 2 objects, storing them in 2 different locations, it considers my statement false, not true. (You and I may have the same iPhone, but we don’t have the same iPhone.) The === operator asks whether they are the same object, not whether they have the same number of properties with the same names and values.

Of course, there are methods for asking JavaScript whether the objects are identical in the names and values of their properties. But, unless we know that mere equality isn’t the relevant fact, we won’t look up those methods, and we’ll simply get the wrong answer.

In my 13 weeks at the Guild, I must have learned hundreds of such fundamentals. I have then forgotten many of them again, too, but repeated practice does, indeed, turn many of them into habits and intuitions.

Getting real

My week 13 ended on 4 August, and during that week I began to migrate, incrementally, toward practicality. I learned how to process forms that users fill out on the web, how to make a web page get information from a server, how to make a website read and write “cookies” on the computers of its visitors, and how to let users create encrypted passwords.

I began to learn, too, how to make a web page that behaves like a calculator. That project kept me busy for another week. I’ll blog about it in a subsequent installment.

In principle, all that emphasis on fundamentals should allow me to be more productive as the work continues to shift toward practical applications. But, in any case, I didn’t mind the immersion into abstract rules. Reality is overrated.

 

Week 12 at an Unbootcamp

Friday, August 4th, 2017

Packages

The week ending on 28 July was my 12th week of study at Learners Guild in Oakland. I worked on 6 different projects. Through them, I learned how to apply more basic techniques of JavaScript web application development.

Some of what we learn is the JavaScript language itself—a language that changes once per year, so that learning never ends.

But it seems that more of what we learn, and will increasingly learn, is packages. They basically do things that you, the programmer, could do with the raw languages and protocols of web programming (mainly HTTP, HTML, CSS, JSON, and JavaScript), but they (allegedly) make it easier to do those things.

During the week my projects required me to learn how to use these packages:

  • fs, which handles directories and files
  • http, which handles transactions between computers
  • cheerio, which interrogates and manipulates documents written in HTML
  • request-promise-native, which manages a computer’s requests to other computers
  • pg, which manages a program’s use of PostgreSQL databases
  • express, a system for combining programs into an application delivered on the web

Some of these packages, in turn, are entire ecosystems to which other developers have contributed packages. For example, the express package has about 12,000 related packages, and the express website names 12 “popular” frameworks built on express. It’s been dawning on me that learning to use packages is only part of the challenge posed by packages. Another part is figuring out which packages to learn to use. This is not trivial, because there are many to investigate, and it can take hours of study and testing before one discovers that a package is not as good for one’s purposes as it had seemed.

As a result, wise folks advise us to choose popular packages. They argue that popular packages are not only vetted by others, but also likely to stay alive long and be updated often. It’s not hard to learn which packages are popular. At the npm site, where most significant JavaScript packages are distributed, you can order the search results by popularity. In a search for “express”, express itself is at the top of that list, and you can see, today at least, that it has been downloaded 543,571 times in the last day. There are also surveys with published statistics on the popularity and “mind share” of JavaScript frameworks. If, however, you want to do something unpopular (e.g., innovative), an unpopular package may be best, or perhaps you should develop your own, or just write your code in the basic languages of the web.

The modules we work on at Learners Guild take various stances on packages, reflecting the diversity of environments we can expect to face in the outside world. They sometimes tell us not to use any package; or to use plain JavaScript to reimplement functions that a package performs; or to use a particular package; or to use any package(s) we may wish to use. In most cases, they prescribe particular packages that are widely used, and that we therefore should become familiar with.

Perhaps some have fantasies of “mastering” a language such as HTML or JavaScript. The more I learn of them, the less plausible such aspirations seem. But the idea of mastering the universe of JavaScript-based programming, including all its packages, is absurd. We are aiming to know a lot, but above all to know how to learn what we need but don’t know. And to ask for help in moderation, and to give help usefully. And to be good collaborators. That’s plenty.

Week 11 at an Unbootcamp

Sunday, July 30th, 2017

The simple is not so simple

During the week ending on 21 July, my study of web application development at Learners Guild had me doing things that seem numbingly simple on the surface. I developed 2 “applications”:

  • One lets you look up the current temperature in a city of your choice.
  • The other lets you look up movies that have some relationship to some text that you provide.

Let’s make this more concrete.

Temperature application

The temperature application is a JavaScript program that runs when you ask it to. You use a terminal window, not a web browser, to run it. In the terminal, you enter a line such as:

node weather Nsoatre

In about a second, you get the reply, such as:

Temperature in Kelvin: 292.59
Temperature in Celsius: 19.44
Temperature in Fahrenheit: 66.99

What my simple application won’t tell you is that it looks up the city you asked for in the Application Programming Interface (henceforth “API”) of OpenWeatherMap, and when you give it a city name it gives you back a response that may or may not have anything to do with that city. Nsoatre is a small town in Ghana, apparently unknown to OpenWeatherMap. Instead of saying it doesn’t know about Nsoatre, OpenWeatherMap gives you the temperature for Saint-Martin-de-Beauville, France. (No joke.) If you name a large Ghanaian city, such as nearby Kumasi, then you do, indeed, get data for that city.

So, why does the Guild have us Learners creating such a useless (or worse than useless) application? As I understand it, the Guild trusts us to distinguish the practical usability of a project from its value as a teacher of fundamental technologies. This exercise helped familiarize me with:

  • Node, the world’s most widely used system to run JavaScript on computers (outside of web browsers).
  • The http module of Node, which simplifies the task of requesting information from other computers.
  • How the http module’s request() and get() methods (slightly) differ.
  • How an information request to an API is constructed.
  • How to show an API that the program has permission to get information from it.
  • How to use a JavaScript callback function to ensure that the program waits for the information from the API before it manipulates that information and sends a reply back to you.
  • How to screen out invalid requests (such as node weather, with no city).
  • The splitting of an API response into “chunks” and how to reassemble the chunks before processing the response.
  • How to round numbers to a particular number of decimal digits after computing them.
  • Debugging code.

Maybe it’s even better for my application to give you laughably unreliable information. Then I’m not tempted to spend time trying to make its answers correct, when that would only distract me from getting the intended benefits of the exercise.

Movie application

The movie application lets you look up information about movies. It’s similar to the temperature application, in some ways. You use a terminal to enter a request such as:

node movie-search Panchali

In about a second, you get the reply, such as:

Pather Panchali (1955)
Apur Panchali (2013)

This application sends your search text on to the Internet Movie Database (IMDB), gets back a web page (the same one, written in HTML, that you would get if you went to the IMDB website and entered “Panchali” into the search bar), analyzes that page to extract from it just the title lines, and sends those title lines back to you.

This application seems to give more reliable answers than the temperature application does, but not perfect. If, for example, you wanted to ask about movies featuring that small Ghanaian town Nsoatre, you would get references to 2 movies: a 1957 TV series titled “Alcoa Theatre” and a 2014 feature titled “Vadelmavenepakolainen”, about a Finnish man who “has dreamed of becoming a Swede since childhood”. I haven’t found any connection between them and Nsoatre, and I don’t intend to work on that problem, so, if you want to, be my guest.

This exercise reinforced most of the topics listed above, but the movie application’s technologies differ incrementally from the temperature application’s. This one helped me become more familiar with:

  • The widely used cheerio HTML parsing library, which simplifies the task of manipulating HTML web pages.

Getting movie title lines from an IMDB search-result web page is not trivially easy. The routine that I constructed to do this, in cheerio syntax, was:

const listCells =
  $('a[name=tt]')
    .parent()
    .parent()
    .children('table')
    .children('tr')
    .children('td.result_text');

This means:

  1. Find an a tag that has the name tt.
  2. Then find that tag’s parent tag.
  3. Then find that parent tag’s parent tag (i.e. the a tag’s grandparent tag).
  4. Then find all of the children of that grandparent that are table tags.
  5. Then find all of the children of those table tags that are tr (row) tags.
  6. Then find all of the children of those tr tags that are td (cell) tags with the class result_text.

So, because IMDB search-result pages are not optimally organized for programmatic analysis, I had an opportunity to spend a few hours learning and practicing the use of the cheerio HTML parsing library.

Of course, I didn’t get it right the first time; this exercise, like all of them, helped me learn how to find and correct my bugs. But debugging is a huge topic; I’ll save that for another entry.

 

Week 10 at an Unbootcamp

Thursday, July 27th, 2017

An unexpectedly short week

We Learners at Learners Guild in Oakland, California, are expected to be present, physically, at least from 9 a.m. to 6 p.m. Mondays through Fridays (with up to 1.5 hours for lunch). There are, however, exceptions.

As reported a week ago, the week ending on 7 July included 2 days of holiday, so it was abnormally short. The week ending on 14 July was a normal week for most, but turned out to be short for me, because of an upper respiratory infection that filled my week and the weekends bordering it. With 3 days of fever and other bothersome symptoms, day after day I was compelled to notify the Guild I was taking time off, a half-day at a time, for the Guild’s own protection.

In principle, a person can do nearly the same work at home when ill, but my condition clearly dampened my productivity. As witnessed by Github, I made 46 “contributions” the week before, versus only 27 during the week in question.

How does the Guild deal with such frailties? It offers a standard allowance of 8 days of personal time off during the 40 weeks of enrollment. Having just taken 4.5 days off, I was now left with 3.5 more days to last me through the middle of February. Once that time is exhausted and starts to be exceeded, a review is triggered. The Guild’s decision could vary from termination, in a case of callous truancy, to the granting of a leave of absence to permit recovery from a lengthy illness. I have, of course, not yet experienced such a review, but I know the people who would conduct it, and their capacity for sensitivity and empathy makes me a cold-hearted ogre by comparison, so I’m not worried.

The Guild is particularly responsive to emotional afflictions. Life can be traumatic, and life as a Learner can be particularly traumatic, given that some Learners have quit real jobs to join the Guild, most find it hard to make ends meet in the Bay Area even with stipends received from the Guild, and for many it’s a radical change from the kind of work and the kind of thinking they have done heretofore. Knowing that one is being periodically evaluated for one’s rate of progress and runs a risk of being found too slow to stay makes some Learners express insecurity. Some Learners have also testified that they have had trouble coping with disrupted expectations arising from the Guild’s recent curricular overhaul and those preceding it. The Guild holds discussions focused on stress, anxiety, disempowerment, the imposter syndrome, and other emotions affecting current Learner life and the future work lives to which Learners aspire. A psychotherapist on the staff offers group and individual counseling for all Learners.

But the Guild’s posture is also tough and demanding. While offering support to cushion the impacts of physical and emotional impairments, the Guild reiterates that its Learners must develop their own resiliance, adaptability, and skill in figuring things out for themselves, and they must participate in the delivery of support, not only its consumption.

Oh, yes, the work

My lethargic progress during the week was confined to one “module”, for which I developed a demonstration (to myself, really) of the use of “callbacks” in JavaScript to manage data in a file. The ostensible purpose of the application was to manage a list of tasks. The user can add tasks to the list, declare them completed and thereby cause them to be removed again, and display the list. A few other embellishments allowed me to give it my own personality.

But at the heart were “callbacks”, one of the main elements in the thought reform I’m undergoing at the Guild. A callback is a routine that waits for something else to finish before it runs. It has to wait, because it needs the result of the other process before it can do its work. Meanwhile, however, the main program is continuing to execute instructions. It is the callback that waits, not the program as a whole. This exercise allowed me to work on learning and obeying the rules applicable to callbacks and, finally, produce a simplified application in which callbacks operate properly. Given the tendency to forget the details (something widely admitted by Learners and not only the geezers among us), such a working template is a reassuring crutch we can return to when facing similar problems again.

 

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.

Week 7 at an Unbootcamp

Wednesday, June 21st, 2017

First week under the new model

As reported last week, Learners Guild in Oakland, California, has just made a major change in its software-development curriculum. This week was the first week of the new model’s implementation.

Under the new model, coding tests and technical interviews allow Learners to progress through 5 “phases”. This is the transition week. All 120 or so Learners are undergoing coding tests and interviews simultaneously. We were all tested from Monday morning until noon today (2.5 days), and then we are each getting a half-hour teleconferenced technical interview sometime during the rest of this week, followed by a decision on our phase placement. It is impressive that the Guild can handle this process for all Learners in the same week.

My own interview took place this afternoon. I was my interviewer’s first interviewee. I survived with my self-respect intact, unlike job interviewees in software who are often reportedly humiliated and demeaned by their interviewers (see, e.g., William Poundstone’s How Would You Move Mount Fuji?.) The interview was friendly and relaxed. As expected, I was mainly asked to explain how and I had solved problems and why I had done so as I did. Occasionally I was also asked what, if anything, I knew about related other methods. If I imagine how I would want to interview a person in the same situation, to help my organization decide where best to place the person in the curriculum, that’s how it went.

Before the interview I spent 2.5 days performing 3 assigned tasks that I doubted I could finish. Somehow, without losing much sleep, I did manage to complete them all. To do that, I had to look up a lot of new information and reawaken some dormant know-how.

I also had to make a decision to violate one of the methodological requirements. It said: Do X, using tool Y. Well, I tried, but after several hours decided I would not have time to figure tool Y (a new tool for me) out. I decided to do X with method Z instead. It’s like, I rationalized, deciding to serve baked potato rather than broiled ham to a customer who has asked for broiled potato.

I was tested and interviewed for admission into phase 3. Phase 3 out of 5? After only 6 weeks out of 40? Yes, because I took seriously, and trusted, the staff’s recommendation to choose a phase ambitiously. I appear to have been more trusting in this respect that my fellow junior Learners, who appear uniformly to have chosen to be interviewed for phase 2. Not terribly consequential, since, if I don’t get admitted into phase 3, I’ll be in phase 2, just like those who interviewed for phase 2, and we’ll all have 8 weeks to get into phase 3. Now that it’s done, I don’t regret trusting the advice to be ambitious. This test kept me doing research, testing, and debugging, and I wound up, probably, learning more from the experience than if I had been working on the prior test’s problems. If it turns out that I almost got into phase 3, then I’ll have the option to re-interview for it as soon as I feel ready.

The extent of the curricular revolution at the Guild became clearer today when the new curriculum’s outline was disclosed to the Learners. It’s a truly magnum opus, although still in progress. A plethora of interfaces have been consolidated into a portal, where we can now see all the phases, the skills they develop, the project modules that we can work on, which modules are good for which skills, an outline of topic lectures to be offered, a photo gallery of all Learners and staff members, a link from each gallery entry to methods for contacting the person, and the basic operation manual for life at the Guild (a.k.a. the Guide). As of this writing, there are 208 skills listed for phase 1, and 160 skills listed for phase 2. Click on a skill, and you go to a page showing which modules you can learn or exercise that skill with. Click on one of those module titles, and you get a page on that module, containing the skills it develops (classified into categories), a glossary of related terms, terms useful in searches for related help, links to many related exercises on the web, and links to many related resources. What you don’t find on the page is a set of instructions giving you a programming problem to solve. That’s the one thing you might have expected in a traditional teaching/learning institution. Its absence is a signal as to how the Guild differs. You’ll get programming problems when you apply to move into the next phase, but in the meantime you are doing your own learning, with published support from the curriculum, personal support from professional engineers, and about 120 other Learners you can always ask for help from.

Now that my interview is completed, I have Thursday and Friday to choose some topics to get familiar with. The new curriculum mentions about 400 such topics, and a few of them became salient during my test and interview. I won’t run out of topics any time soon.

 

Week 6 at an Unbootcamp

Friday, June 16th, 2017

No ordinary week

“Cycle 47” was a special week in my career makeover at Learners Guild. The old Guild is no more; enter the new Guild.

Detour

First, the week was abbreviated, for me, by a day and a half of jury duty. I was confident I would never survive the peremptory challenges in any jury selection: I’m too iconoclastic and steeped in litigation. This was a residential eviction case, where the defendant was claiming retaliation. I myself had just moved out of a co-op in anticipation that its members would perpetrate retaliatory eviction against me. How could the landlord’s attorney let me onto that jury? But she did. The tenant’s attorney asked whether, despite my involvement in numerous prior eviction cases, I could be unbiased in this case, and I said no, I could not be unbiased. But he still didn’t challenge me! Both attorneys exhausted their challenge allotments on persons who, in my lay judgment, were less risky for their clients, but not on me. So I actually got onto the jury. We heard our instructions and witnessed a couple of hours of botched testimony by a landlord witness, who said his firm normally complies with the law on evictions but admitted he didn’t know whether it had complied in this case. Why this case ever reached trial was a mystery to me. And the next morning we were informed that the case had settled, so we were let loose. Before leaving the courtroom, I asked the landlord’s attorney whether her client couldn’t have prepared better for this trial, and she agreed.

Back at Learners Guild, I resumed work on my Goal on Wednesday. “My”, because the Algorithm had assigned me to my second-choice (solo) Goal rather than my first-choice (team) Goal. Had I been on a team, I would have asked to have my jury duty rescheduled, in fairness to my teammate.

The nitty gritty

The Goal required solving 8 logical problems, called “coding exercises”:

  1. Scrabble tally: Given a list of tiles already used, return a tally of all letters, grouped by the counts of their remaining tiles. I chose to implement it generically, so it would work for any language’s version of Scrabble, or any other structurally identical situation.
  2. Word lookup in a string: Given a string (i.e. a line of text) and a number, return the word that is at the number’s position in the string, where the first position is zero. I chose to implement it with the XRegExp library, so it would work for any language, not just English. Whether for English or generically, one must define “word”. For this exercise, I defined the words of a string as what are left when we treat any sequence of characters matching the regular expression “[^\pL\pN]*\pZ[^\pL\pN]*” as a delimiter. That means any sequence of 0 or more characters other than letters and/or numbers, provided that it includes at least 1 separator character (using Unicode’s definitions of letters, numbers, and separators). There is no universally satisfactory rule defining “word” in all languages, or even in English. Mine was a quick-and-dirty rule. It classifies “M&M.” as a word in “He ate an M&M.”, and “Mr” as a word in “Mr. Smith”.
  3. Translator between (ordinary) decimal numbers and binary numbers with the Fibonacci sequence as the base. (We who love to solve problems don’t ask, “What am I ever going to need this for?”.)
  4. Function that removes vowels, defined as “a”, “e”, “i”, “o”, “u”, and all non-a-to-z characters (even A-to-Z), from a string. Defined naïvely and Anglocentrically, so I couldn’t try to universalize it. Lucky for me; that could have taken a lifetime.
  5. A search tool to find a value inside a JSON string. JSON seems to have taken over supremacy from XML as a format for exchanging complex bodies of information. Its advocates say it’s “much simpler”.
  6. Date reformatter: Converts from any of 6 formats to the ISO 8601 standard format, like “2017-06-16”.
  7. Music player: A web page that, as soon as you open it, plays the notes of an octave and, optionally, a chord. Why was this included here? Sure, it’s coding, but it also involves researching how to generate and play sound. That’s what took the most time for me.
  8. Parenthetical redundancy eliminator: Given a string, return the same string, with any redundant pairs of parentheses removed. Not as simple as it may seem. For example, “ak⁾vo (((water [[(H₂O)]])))” contains no redundant pairs of parentheses, because brackets and full-width parentheses are not (in my solution) classified as parentheses.

That, then, is a taste of the kind of thinking we learn to practice at the Guild.

Would the detour hurt my grade?

Given the interruption, I doubted I could complete the 1-week Goal’s requirements by Friday afternoon. My coach reassured me that my completion score on this Goal would not suffer from my jury-duty absence, because scores were adjusted for time off. In any case, I managed to finish the 8 problems on Thursday, so I used the remaining time to start some of the Goal’s optional work.

Anyway, grades didn’t exist at the Guild. Statistics and levels did, though, and it’s hard to avoid assimilating any quantitative indicator into one’s mental model of grading at school. Even without grades, I have been seeing a considerable amount of grade anxiety among Learners, attached to what are the closest approximations to grades.

Revolution from above

Little did my coach or I know that the week’s work was not going to be scored for completion at all. We did get a hint of this on Monday, when the staff advised us not to worry about completion scores that week and to focus only on learning as much as we could. But the deeper reason for this advice was revealed only on Friday.

Learners Guild solicits comments from its Learners, and it gets many unsolicited comments as well. Its staff makes changes in the process in response to those comments.

On Friday afternoon, when I normally would have been composing this blog entry (well, a blog entry, since the content would have differed), we spent 3 hours learning of, asking questions about, and discussing a new batch of changes to the system. This one was no set of incremental adjustments. It was fundamental.

The Guild has now jettisoned its entire apparatus of statistical progress (and regress) indicators, which had been refined for months and was about to be re-refined. By one staffer’s own testimony, the repeated attempts to make that system satisfactory had led to a conviction that doing so was hopeless, so, in mid-tweak, the system was trashed.

The set of “levels” through which Learners moved on the basis of their statistical indicators has likewise been thrown overboard. This vertical (higher and lower) metaphor has been replaced by a horizontal one: “phases”.

Phases might seem like a mere renaming of levels, but they are not:

  • The phases differ in their content. Phases 1 and 2 are self-paced individual work devoted to mastery of prescribed fundamentals. In those phases, no more do Learners vote on preferred projects; instead, there is a fixed set of skills to be acquired. Phase 3 is team-based small projects with choice, like what I have been mostly doing up to now. Phase 4 is collaborative work on real (not just realistic) open-source projects. Those two project phases, 3 and 4, are not rigidly tied to a 1-week cycle. And Phase 5 is preparation for the reality of the external market for the Guild’s product, web application developers.
  • Admission into the next phase depends on a 1-week testing and interviewing filter. We should expect on average to be ready for that after about 5 weeks in a phase, but we must get into the next phase in no later than 8 weeks; otherwise, our progress is not satisfactory. If we don’t get admitted on our first attempt, we get an additional opportunity to try. Phase 5 is not subject to that limit if it would eject us before our 40 weeks at the Guild has come to an end.
  • Learner-to-learner coaching is no longer a formal element of the system. Instead, we are supported by “Software Engineering Practitioners”, who are Guild employees. To see the qualifications of an SEP, look at the current hiring announcement. If you yourself are qualified, please apply and mention my blog as your referral source. While coaches are no more, the Guild hopes that its abandonment of microstatistical indicators will make Learners more relaxed about taking time from their work to help other Learners. Thus, if it works, coaching will become culturally pervasive, instead of being an assigned temporary role.

The path from here to there

The Guild seems to have defined a reasonably smooth transition for existing Learners into the new order. This week we are on a pre-scheduled 1-week break. Next week we all undergo a “sorting” process. To prepare, each of us has notified the Guild which phase he or she asks to be evaluated for. Starting Monday morning, we work individually on projects constituting take-home tests for the phases we have chosen. Starting Wednesday afternoon, we get interviewed by SEPs on the solutions we produced, to evaluate our (in)ability to explain and reason about our own solutions and possible alternatives. At the end of the week we learn whether we have been admitted to the phases we selected; if not, we are admitted to the preceding phases.

The Guild program lasts, nominally, 40 weeks (plus 1 or 2 break weeks). If the transition places a Learner into a phase that makes the program longer, then it is extended for that Learner.

I have been at the Guild for 6 weeks now. That should qualify me to get into Phase 2. But the Guild advises us to try to get into the most advanced phase we “think” we “can” get admitted to. I have probed for clarity about that, and I believe the intended meaning is the most advanced phase we believe the SEPs have a nontrivial probability of letting us into. So, if my subjective probability of success in getting into Phase 3 is 30%, I should try for Phase 3. That’s close to my subjective reality, so I have asked to be tested for Phase 3. If I were to succeed, I would feel a need to backfill my fundamentals, and I’d be doing so under pressure to complete current projects, but that’s probably typical of the real software-development world.

Who’s the guinea pig?

Abrupt change can be exhilarating or frightening, and the changes can benefit some while harming others. The Learner population is diverse in many ways, so the personal impacts of this redesign will vary.

At least one Learner has said that the Guild feels like a laboratory in which she is one of the subjects in an experiment.

There is a basis for that impression. The Guild exists only in Oakland but aspires to replicate itself. We are testing each iteration of its design and helping the Guild decide what to keep and what to change. The system must work for us before it can be scaled up and out.

While acknowledging the validity and empirical basis for the sense that the Guild is experimenting on us, I have a different feeling. For me, yes, there is an experiment going on, but in that experiment I am the experimenter and the Guild is the subject.

I am conducting an experiment (or, perhaps better, pilot study) testing the hypothesis that there is no chronological limit to professional rejuvenation, even in information technology. I invited the Guild to join that experiment, and it agreed. As time passes, I keep providing stimuli to the Guild, and it keeps responding. Step by step, I’m discovering what makes it tick and how to get my needs satisfied by this subject, who is simultaneously a subject in 120 other engineers’ experiments, testing similar but not identical hypotheses. In this interaction, I perceive more autonomy in myself than in the Guild.

I have also heard the suggestion that the Guild may be breaking its contract with Learners when it changes its system. I have my doubts about that, and in fact I would probably entertain such a notion if the Guild refused to change its system, because, arguably, that would be negligence.

But these are subjective matters. If you are considering applying to the Guild, considering the testimony of other Learners and me may help you predict what your own interpretations would be. If you are risk- and change-acceptant, I believe that’s a good sign of compatibility. Perhaps only such persons are a good fit for contemporary software development work anyway.