Week 1 at an unbootcamp

There is an unusual software development school in Oakland, where unusual people learn. I have just experienced a week there. I’ll tell you about it.

I’m upgrading skills to become qualified as a “full-stack” (do-the-whole-thing) developer of web applications and related software.

Anything unusual about this? Yes:

  • Demographics
  • Financing
  • Program

Demographics: I’m doing this together with about 120 others, and as a group we are atypical. There are more women and more nonwhite members of this group than in computer programming generally. I, too, am an outlier, being 74 but preparing to work in a youth-dominated field. The Bureau of Labor Statistics reports that 5.9% of employed persons in the U.S. in 2016 were 65 or older. Among “Software developers, applications and systems software”, it was 2.4%. Among “Web developers”, it was a mere 1.5%. So, the geezeriat constitutes only 25% to 40% as large a share of web application developers as of the entire U.S. workforce.

Financing: This program finances itself by using “income sharing agreements”. Participants pay nothing to attend, but they must pay back to the program a fraction of their earned income for several years after exiting. The investors are treating each participant like a startup company, gambling that the participant will earn enough and soon enough to more than repay the amount invested. This model exists in tertiary education and in private vocational training programs, but it is still rare. Ideally, it aligns the incentives of the investors with those of the investees, diminishing the reward for skimping on efficacy. It is also morally ironic (and perhaps morally problematic): I have a duty to try to earn money, so I can be true to my bargain, help the program succeed, and avoid free-ride guilt.

Program: The program runs for 40 weeks, versus so-called coding bootcamps, which usually last about 12 weeks. It is more participatory and holistic. It aims to emulate and prepare us to use rapidly changing technologies in an industry where almost all work is teamwork. How? By cultivating the ability to learn new methods fast, to give and receive help, and to navigate the personal, organizational, and societal environments of our work. Further, it defines competence as not only the ability to do things, but also the ability to understand, explain, and manage the things we do. There are no teachers here; the knowledge, authority, and initiative characteristic of teachers are distributed among us. Expertise is available as needed in one-on-one and group encounters, but its supply is limited, so we get advice and practice in making good use of it and, as we develop it in ourselves, sharing it effectively.

So, here I am, finishing my first week as a “Learner” at Learners Guild in Oakland, California, where I began on 1 May 2017. How was this week different from all other weeks?

It began on Monday morning with “What do you want to get better at this week?” I got acquainted with the “Goal Library”, containing specifications for dozens of tasks, classified as to difficulty, technical focus, job-market value, and team size (from 1 to 4). I got some advice, but nobody told me which Goal to choose. Instead, I cast my votes for 2 of the Goals. While voting, I could see the up-to-the-second vote tally and, if I wanted, could vote strategically to be the second voter for a 2-person-team Goal, improving my chance of getting assigned to it. An algorithm does the assignments. It considers even how Learners have rated working with each other in the past, to limit intra-team friction. I got my first choice, a Goal requiring me (alone, because it is a 1-person Goal) to implement 5 computing algorithms in JavaScript. For example, if your program is given a set of points in 2-dimensional space, it must identify a pair of points that are as close to each other as any other pair drawn from the same set of points. The “Project” of implementing these algorithms and properly sharing my solutions was most of my work during the week.

As I solved the problems posed by my Goal, I sought advice from the Project’s “Coach” (a more experienced Learner). Coaches also met every morning in a group with those they coached for a quick “standup”. I had access to the other Learners in the Guild’s sprawling quarters, both face-to-face and in the Guild’s instant-messaging forum, as well as the outside world. (Tuesday my wife said I should think about solving the graph-connectedness problem recursively, and she turned out to be right.) During this first week, there were extra meetings for us new arrivals with our “Mentors” (more advanced Learners) and staff. The Guild also has plenty of how-to literature to get familiar with.

Friday afternoon, after finishing and polishing up my work, I submitted it for evaluation, discussed solutions with Learners who had been assigned similar Goals, and (this, too, is a prescribed item on the schedule) reflected individually in a manner of my own choosing on what the week had wrought. (I chose to reflect by writing this blog entry.)

Everybody who joins the Guild has written software before, even if only during the weeks of required preparation between admission and enrollment. I had done so off and on for almost 50 years in academia and small nonprofits. But the industrial discipline here was somewhat new to me and added challenges to those posed by the Goal itself. That discipline includes:

  • Linting: subjecting the code to automated validation for stylistic consistency.
  • Respect for the specifications: writing a program that does what is prescribed, not what I feel like making it do.
  • Test-driven development: writing multiple tests of a program before writing the program itself, and relentlessly imagining weird conditions to craft tests for. (For example, what if the set of points is empty, or its points are all in the same place?)
  • Maintainability: writing and documenting code that is practical for me (or others) to modify as needs change.
  • Code reviews: getting others to examine my code early, so I can make improvements before it is too late.
  • Deliverability: as top priority, satisfying the specifications on time. Any optional frills can be added after the minimum required product (called the “artifact”) is complete.
  • Customer focus: I’m writing code for others, not for myself, so I must document what it promises to do, how to install and configure it, and what license terms it is released under.
  • Collective development: Most of the Goals (like most industrial software development) are performed by teams, which must decide how to share (and/or split) the work. Whether it’s strategy, style, sequencing, or what time to go to lunch, teamwork creates obligations but makes big projects possible. It is less prominent in “1-person” projects, but their developers collaborate across projects.

Even one week has been enough to start noticeably enlarging my skill set and changing both how I work and how I think about work. That’s a sign that the Guild is doing what it was designed to do.

A month in, the Guild and each Learner review their relationship and decide mutually whether it merits 35 more weeks. I’ll let you know how it goes.

3 thoughts on “Week 1 at an unbootcamp

  1. Yeah, def interesting (even if “Learners” is a bit Orwellian). Sounds like a great way to spend the day !

Leave a Reply

Your email address will not be published. Required fields are marked *

Edit translation
Machine translation (Google):
Copy to editor
or Cancel