Archive for August, 2017

Week 15 at an Unbootcamp

Saturday, August 26th, 2017

Programming in a team

The week ending on 18 August was my 15th week at Learners Guild, where I’m learning to use the tools of a web development engineer. More accurately, I’m learning how to learn those tools, given that they are always changing.

How to learn? Well, it’s a combination of reading documentation, reading or viewing tutorials, reading questions and answers on fora such as StackOverflow, examining tools’ code, asking experts, asking peers, inserting debugging statements into one’s code, inspecting network interactions and document properties with browser-based developer tools, and testing one’s hypotheses about what a tool will do under specific conditions.

It was my first week in what is now known as “phase 3”, out of the 5 phases of the Guild’s revamped curriculum. Adjusting to the change from solo study to teamwork was straightforward, since I had gotten used to team programming as the normal mode before the curriculum reform.

booklistWe developed a web application that interacts with a make-believe database of books (maintained by the Guild). Using it, you can view the list of books, view and amend details, add a book to the list, or delete a book from the list. Yes, you can do those things, because it’s just for practice, and anybody can reinitialize the database with its original content at any time.

Want to try it out? Be my guest. The description of our project and the code itself are at my Github repository site.

As described there, we actually developed 2 versions of the application. Change the “1” to “2” at the end of the address, and you can try the other version. We didn’t intend to do that. Initially we agreed that my partner would work on the database interface, and I would work on the user interface. We didn’t appreciate how interdependent those were, so in order to test our own work we felt a need to develop some features in each other’s domain. It ended as parallel development more than pair programming. That’s not a sin, but it illustrates the need to decide what kind of collaboration a team will practice.

Up or out?

The week was special for the Guild as a whole. It was the 8th week of the new curriculum, and therefore the final week of each Learner’s opportunity to qualify for the next phase, under the new rules.

The professionals conducting the evaluations have been strict enough, and Learners’ success in adapting to the new curriculum has been variable enough, to bring about a non-negligible failure rate.

What happens when a Learner tries twice to qualify for the next phase by week 8 and doesn’t succeed?

That was the week’s Big Question. The official policy announced during the curriculum reform was that such a failure might result in immediate termination of the Learner’s participation in the program. By popular acclaim (over my legalistic objections), Learners interpreted “might” as “will”.

Well, termination turned out to be the third rail of Guild politics. Protest, resistance, community organizing, manifestos, frenetic messaging, caucuses. In short, turmoil. Numerous Learners reported that they hadn’t gotten much work done that week because of the existential threat to Guild life as they knew it.

The rhetoric was notably solidary, not alienated. Learners, almost unanimously, embraced the Learners as a community and expressed a desire to improve the Guild and stay there, not give up on it.

The Guild’s leadership awoke. The intense reaction put the Guild under pressure to justify the up-or-out policy. Some institutions would defend and persist. Others would relent. The Guild responded more subtly. After long meetings full of persuasion and tears, the Guild agreed that it had (1) insufficiently involved the Learners in the design of the new curriculum and the adoption of related policies, (2) not shared enough information about the Guild’s business model and financial condition to let Learners give informed and realistic advice about a termination/retention policy, (3) closed off some of the prior channels for Learners to submit ideas, (4) failed to accompany the new curriculum with a plan for validating and revising both the curriculum itself and the minimum required pace of progress under it, (5) not made plans to take advantage of the presence of multiply disadvantaged Learners as testers of a curriculum aimed at maximing equality of opportunity, (6) given insufficient practice to Learners in the code-explanation skill that is a major requirement in the end-of-phase evaluation, (7) not seriously examined the need and opportunities for differentiation of the learning/testing experiences to accommodate cognitive and social diversity in the Learner population, and (8) possibly given excessively advanced initial phase assignments to some Learners, artificially impairing their efforts to satisfy the progress requirement.

Consequently, the Guild imposed a 2-month embargo on possible terminations based on insufficient progress. It embarked on extensive staff and staff-Learner consultations on how to remake the Guild together.

The entire coding-bootcamp industry is under scrutiny these days, with some arguing that only those that reinvent themselves will survive. It may be opportune that Learners Guild’s next revolution has just begun.


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


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.