Archive for the ‘1. Work’ Category

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 in 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.

 

Week 5 in an Unbootcamp

Friday, June 2nd, 2017

“Cycle 46” is ending today at Learners Guild. Each cycle lasts a week. For me, this is week 5. Cycle 46 is a 4-day week, because of Memorial Day, so there has been a bit of pessimism in the air about whether the Learners would have enough time to complete their various projects. But not much. The Guild reminds us not to over-focus on our completion statistics.

Week 5 was my first encounter here with rejection. The Algorithm gave me my first-choice Goal to work on, together with another Learner, but he had not voted for it or, in fact, for any 2-person Goal. He wanted—desperately—to work on a 1-person Goal and asked me to give up my assignment so he could get a Goal that he wanted. It was, he said, part of a self-designed curriculum. I didn’t have the authority to change my assignment, but the staff does. I agreed to go along with his plan. The staff probed him for justification, but gently, and he didn’t yield, so the staff reassigned us—me to a 1-person Goal that was on my agenda. An agreeable outcome from my perspective: I’ve been spared during this 4-day week from negotiating roles with a teammate, and particularly with a reluctant and perhaps resentful one.

Is it beneficial for the Algorithm to impose its unknown rules, including some inevitable unpredictability, as it accepts or rejects the Goals that Learners voted for? Welcome to the real world. I have to assume that I, too, shall find myself some weeks working on Goals I haven’t voted for. So be it. We’re learning to do work that the world wants done (and is willing to pay for). The Algorithm is my boss, and bosses can be tempermental. We need practice in accommodating that.

I managed to complete the specifications on Thursday morning, so I had time to extend the project. Among the topics I explored further were execution efficiency and internationalization.

What’s most efficient isn’t obvious at first glance. Suppose you want the computer to inspect a sequence of characters (i.e. a “string”) and report whether it satisfies some criterion. The criterion posed in this case was whether the string is a palindrome: a string that is identical to its inversion. For example, “pool” is not a palindrome, but “poop” is. How can you instruct the computer to check this efficiently? One answer is: Tell it to make a inverted copy of the string and then to report whether the two strings are identical. It turns out that this is not the most efficient thing to do, at least in JavaScript.

  • If you think about it, you can see that this method requires the computer to do twice as much work as necessary. A comparison of “pinonip” with its inversion, i.e. “pinonip”, compares “o” with “o” once, but compares “p” with “p”, “i” with “i”, and “n” with “n” twice each. But checking the first 3 characters is enough: if “pin” is the same as “pin”, then the full string must be a palindrome. Any non-palindrome, such as “pinonap” (inversion “panonip”) will be detected within the first 3 comparisons.
  • Once you decide to compare only the first half with the second half’s inversion, how do you do that? Inverting the second half and then checking whether the two half-strings are identical is one method. But it turns out to be inefficient. It requires creating a new string. Another option is to compare the existing half-strings character by character, counting forward in one and backward in the other, using a “loop”. That runs faster. On my computer, it runs about twice as fast. To answer this question empirically, I needed to run my program on a string about 10 million characters long; much shorter strings were processed so fast that it was hard to measure the difference.

As for internationalization, the Goals I have seen so far are agnostic about the multiplicity of scripts, and they seem to reflect a tacit assumption that text is always in the Latin script and limited to the printable subset of the ASCII character set (roughly what you see embossed on the keys of a U.S. keyboard). The palindrome problem’s specifications told us to remove spaces and punctuation marks from the string before checking whether it is a palindrome. It also told us to convert all upper-case characters to the corresponding lower-case ones. Its sole example was limited to ASCII characters. I made my solution international by defining “spaces and punctuation” as all characters other than those classified by the Unicode Standard as “letters” and “numbers”. To make JavaScript implement those categories, I installed a package named XRegExp in my project. Some programming languages do that without extra packages, but JavaScript, in its current version, still needs that external tool.

The help I received from more expert personnel here included answers to my specific questions when I failed to find them on my own, but also suggestions that went beyond answers. A suggestion like “I think your solution is not as efficient as one that loops through the existing strings” was enough to send me on my way investigating the issue. Formal instruction this isn’t. My hunch is that it is more effective. For one thing, I never doze off during it.

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.

Upwork encourages obfuscatory verbiage

Monday, July 27th, 2015

Upwork, a major service that arranges contractual work, has just issued some advice for clients communicating with workers across language barriers:

You may be working with a freelancer for whom English is a second (or third!) language. Use clear and straightforward communication by avoiding metaphors and easy-to-understand vocabulary.