Archive for May, 2017

Our mistakes

Friday, May 26th, 2017

GiveWell has a website with a common layout but an unusual twist. There are 7 topics on its navigation bar. What is special is topic 5: “Our mistakes”.

Week 4 in an Unbootcamp

Friday, May 26th, 2017

Another week of my career makeover at Learners Guild has elapsed. I’m almost disappointed to report that it was free of crises.

My teammate has been at the Guild about 20 weeks, so this week gave me a chance to experience asymmetry in experience. It’s actually a bit complicated, this asymmetry. You might think it means A knows a lot more than B, so the information flow is all from A to B. Or maybe A asks B to perform some easier tasks that are within B’s competence. Or perhaps A does the work, explaining it to B.

It may be like that in some cases, but my experience differed. In fact, there are thousands of factoids and skilloids in our environment, and there is a good deal of choice open to Learners, so it simply isn’t true that A knows everything that B knows and then some. What’s surprising to me (although it happens to my wife and me a few times a week) is that A and B each know things that the other doesn’t know (or has forgotten) and that the knower assumes are utterly basic.

Today, for example, our coach was reviewing our code, and he noticed the line “continue arg0” in my code. The keyword “continue” gets out of the current iteration of a loop; it’s like “Stop checking this one”. That keyword is enough if you want to get out of the immediate loop. But, if your loop is inside another loop, and you want to get out of both at once, “continue” alone won’t do it. (Imagine you are checking every department within every university, and if you find any department headed by a robot then you can classify that university as one that has at least 1 robot-headed department, so you can proceed to the next university [not the next department].) For that, you need to label the outer loop and then specify it by appending the label to “continue”. I knew that convention well and presumed “everybody” did, but my teammate and coach were unaware of it. There are more cases of the opposite, but the fact that the knowledge gap is even slightly bilateral seems to promote an egalitarian style of shared work.

You might think that computer programming is all about precision, but people use ordinary language to tell each other what the program needs to do. It’s hard to be precise in writing specifications for software, just as it’s hard to write precise specifications for a construction or design project. Ambiguity is pervasive, and that’s true for software specifications, too. Our project this week was to reimplement, using the latest features of JavaScript, some functions performed by a software library named Underscore. Our specifications told us to use the Underscore documentation as our guide to the desired functionality. Here’s the Underscore description of one function:

first   _.first(array, [n])

Returns the first element of an array. Passing n will return the first n elements of the array.

OK, so you give _.first an array (which is a linear list of items), and optionally you may also give it something else. If you give it only the array, it gives you back the first element (item). If you also give it a number, it returns that many elements, starting from the beginning of the array, rather than only 1 element.

Clear? Not at all. A clear specification would need to say what the function does under various conditions, including:

  • You give it nothing.
  • You give it only 1 thing, but it isn’t an array.
  • You give in an empty array, so it has no first element.
  • You give it an array and something other than a number.
  • You give it an array and a number, but the number is any of these:
    • Negative.
    • Larger than the count of elements in the array.
    • Zero.
    • Fractional (such as 4.75).

There’s more. If the array’s first element is a pointer to a complex item (such as another array or an “Object” (something that has properties and routines you can tell it to perform), should the function return a pointer to that same complex item, or to a brand new item identical to the original one? It will make a difference as soon as anything changes that complex item.

This week I mostly exercised discretion to interpret ambiguous specifications as I saw fit. My usual principle was that the function should not guess what its user wants. My teammate, by contrast, tested Underscore itself to determine how it actually behaves, and he wrote his functions to emulate that behavior.

So far it seems that the Guild’s more advanced Learners and its hired professionals are tolerant of stylistic and even definitional divergence between members of a team. They nudge us, but they don’t crack the whip. And they all recognize that not all of the nudging will be consistent. Dealing with ambiguity, and with ambiguity about how to deal with ambiguity, is one of those skills we learn and practice here.

Week 3 in an Unbootcamp

Friday, May 19th, 2017

Learners Guild continues to provide a challenging and supportive learning environment for my current improbable goal. Reminder: that is to become a competitive web software developer (once I’ve turned 75). Somebody who can make servers and browsers in all kinds of devices (computers, mobile telephones, microwave ovens, you name it) cooperate. Working at an industrial level of efficiency and quality. Improbable for reasons already discussed.

In this week’s project my teammate and I wrote programs that manage basic kinds of collections. It was an opportunity to review those structures (doubly linked lists, queues, stacks, etc.), see how JavaScript supports them, and learn how to manage them both with and without relying on all of the language’s features. Basic stuff, but at the same time we became a little more adept at test-driven development, management of collaborative software repositories, asking for help, and effective work in heterogeneous teams.

Learners Guild is no longer growing its student body. It announced today a decision not to enroll any more Learners until August, when more of its earliest enrollees will have departed. In the meantime, it’s working on adding professional support, so Learners can consult experts more expeditiously. It announced a job today in that category (tell your programmer friends!). I don’t notice much of a deficit in the supply of consultable expertise yet, since I’ve been here only 3 weeks and am surrounded by Learners who know a lot more than I do. And they are a helpful lot.

Asking for help takes more than pride-swallowing. JavaScript is an “unopinionated language”. That technical term refers to a programming language that offers multiple ways to solve any given problem and does not define one way as “superior” to the others. So, one can’t ask about the right way to do something. It’s more complicated. One asks about the efficiency, error-vulnerability, maintainability, popularity, side-effects, and other aspects of various ways to do it.

To illustrate this at a trivial level, there are style-policing (“linting”) programs that we are required to use, but we get to choose which program, and that program does not enforce its style; rather, it has the user define his or her style and then enforces that. Do you want to indent with tabs or spaces? If spaces, how many per indentation level? Do you insist on ending every statement with a semicolon? Do you want to make yourself use single or double quotation marks? In my team this week, I was a semicolon user and my teammate was not. Incompatibility? No. First, neither of us was dogmatic about that. Second, we used a linting program that not only tells you about violations of your chosen style, but corrects them automatically. Run it with the “–fix” option, and hundreds of violations just disappear in a fraction of a second. Change your style definition and run it again, and you have the same software in the other style.

Want a program that does this for the entire Chicago Manual of Style, the Blue Book, or Strunk and White? Learners Guild might help you learn how to make it.

 

Week 2 in an unbootcamp

Sunday, May 14th, 2017

Last week I wrote about starting a retooling adventure. I’ve gone back to school. The school calls itself “Learners Guild” and gathers statistically improbable apprentices in software development. They learn from experts, from each other, and from deadline-driven projects. The financial model is a study-now, pay-later “income sharing agreement”.

I’ve just finished week 2. I partnered with another week-2 learner. Together we wrote programs to reproduce the behavior of about 40 already-existing programs in a popular software library named Lodash. By doing that we fulfilled the requirements of one goal in the Guild’s Goal Library.

Why in the world would we spend a week making something that others have already made? It’s not an unrealistic thing to do, actually. Like any actively used programming language, JavaScript is evolving. One standard (ES5) was published in 2009 and another (ES2015) in 2015. Lodash was created to add features to ES5, but many of those features, or parts thereof, got incorporated into ES2015. So a new Lodash-like library based on ES2015 would be simpler. Some of its functions could merely call ES2015 functions. Others would need to perform additional operations, but would be more compact and efficient, relying on more powerful features of ES2015. Projects like this exist in the real world. This one also focused our attention on, and gave us practice with, some of the newest features of JavaScript, those introduced into the language in 2015.

For me the week also demonstrated the complexity of the dance called software development in teams. Even a team of 2 makes use of an elaborate protocol, named “Git”, to manage their contributions to the code they are writing. That would not be true if they did everything together, agreeing on each line before entering it. But it is true if they split the work into parts and work individually on distinct parts. There are other competing collaboration-management protocols, but Git has emerged as the most successful competitor.

Sorry, I can’t report any teamwork drama. We split up the work, discussed solution strategies, and reviewed and revised each other’s code. Differences in style and tactics? Sure. But they were easy to work through. By week’s end, we thought we had done everything required by the specifications, but our first reviewers found a few deficiencies in our compliance with rules we didn’t know existed. So we learned more about not only how to satisfy the explicit specifications, but also how to infer expectations that the specs don’t expressly state.

A couple of these discrepancies related to a spec requiring us to write the code in the ES2015 version of JavaScript. ES2015 introduced new syntax not previously valid, such as a more compact way to define functions, with arrow symbols, and more restrictive types of variables, declared with new keywords (“let” and “const”). It doesn’t mandate the use of the new syntax but only permits it. We didn’t use these new syntactic features at first but were advised by reviewers that we should. So, now we know that, if we’re told to use a new version of a language, that brings (or at least may bring) with it an expectation that features introduced in that version will be used as much as is practically possible.

When we tell a reviewer that we are surprised by such a tacit expectation, the reviewer urges us to propose (using that same Git protocol) a proposal for a modification of the specs to mitigate the misunderstanding. Yesterday I submitted such a proposal. Git will notify me of any actions taken on the proposal.

 

 

Week 1 in an unbootcamp

Saturday, May 6th, 2017

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.