Archive for the ‘1. Work’ Category

Week 30 at an Unbootcamp

Wednesday, December 6th, 2017

N steps forward, one step back

During my 30th week at Learners Guild in Oakland, California, ending on 1 December, I worked mainly on a web application that manages a document repository. Its ostensible purpose is to let users find and retrieve relevant documents from a collection. The collection might be your own, and you might be the only user. Or it could belong to an organization that has users of various kinds. In addition to this purpose, it has two ulterior purposes: (1) to make me learn or relearn methods for developing complete web applications, and (2) to show others, someday, what I can and can’t do as a web developer.

My inspiration has been a collection of documents in my possession, generated within an organization, with various categories of users having various rights to see and retrieve documents. Some of the documents are open to the public, some only to members of the organization, some only to its current directors, and so on. In my previous work at the PanLex project, I also encountered several archives of language documents whose donors had attached various access restrictions to them.

In designing the application, I decided to focus initially on three functionalities: (1) managing the application’s users, (2) regulating user access to documents, and (3) facilitating user discovery of relevant documents. In addition to making decisions about these functionalities, I also decided how generic to make the application.

Initially I semi-consciously chose to give the application a generic tentative name (“DocSearch”), but in reality to embed into it dozens of assumptions specific to a single use case. While working on it I gradually became more conscious of, and committed to, genericity. As I did, I undid and redid many things to separate the specifics from the application logic. The specific messages to users came out of the code; I put them into a file of their own, where they could be replicated in another language for a user community using that language. Then I isolated into one file the customization decisions that an administrator of a DocSearch site would make and protected that file from being overwritten in an upgrade of the software. Initially, I hard-coded into the application a set of user categories. Later I recognized that as anti-generic, so I redesigned the system of user categories to allow an administrator to define them afresh.

In addition to the genericity problem, there is also a problem of ambition creep. I produce something and make it work, but in a day or two it becomes obvious that this feature is confusing or inelegant. I have a great idea for improving it. So I do. And that improvement breaks something, turning a working inelegant application into a more elegant application that crashes. That sends me into debug and repair mode.

This develop-reconsider-revise rhythm isn’t the only possibility; one can do more thorough initial planning. I sometimes do. But I more often jump into development with only roughly formulated ideas, and then there’s backsliding along with the progress.

I’m not willing to claim that more thorough initial planning is always better. I respect it, but the most difficult problems seem to exist in both scenarios, and attacking them early by starting ad hoc may help solve them sooner. In any case, progress has eventually been outrunning regress. In a few days I may be ready to release the zeroth version for you and others to test. “May”, I said.

 

Week 29 at an Unbootcamp

Tuesday, December 5th, 2017

Recalibrations

Learners Guild in Oakland, California, where my 29th week ended on 24 November, has been further adjusting its web development training program.

When I arrived in May, the program was 40 weeks long, distinguishing the Guild from so-called coding bootcamps, most of which claim to prepare their students for programming jobs in about a quarter of that time. Now the Guild has announced that it intends to trim that duration 10%, to 36 weeks, still leaving it an unusually long program. After 29 weeks there, I can testify to the value of a program that lasts 9 or 10 months. There is far more worth learning, even in the JavaScript ecosystem that the Guild concentrates on, than anybody can assimilate even in that long a period. Sure, the learning might be made more efficient than it has been, but, to dramatically increase my learning rate, the Guild would have needed to spoon-feed me, and then I would not have had abundant practice in figuring things out for myself, something that is hard to learn except by doing it.

The month after I arrived, the Guild adopted a new progress model, partitioning the Learners into 5 “phases” involving increasing levels of complexity. Later phases 4 and 5 were combined. And now phases 1 and 2 have been combined, too, leaving 3 phases, named the foundations, practice, and apprenticeship phases, in increasing order.

The actual work in the phases, too, has been modified during the last months in various ways. It’s hard to describe these changes, because, while they have been going on, the Guild has relaxed the requirements and Learners have taken initiatives to adopt specialties beyond the existing curriculum. Blockchain development, React/Redux, React Native, and Python are the most common additions I have seen Learners deciding to make to their skill sets. The Guild is considering bringing some of these hitherto unofficial subjects into the curriculum.

In adopting phases, the Guild created a mechanism for moving from one phase to the next. Initially, it was a one-week evaluation, starting with a multi-day take-home coding exam followed by a one-hour interview on the work that the Learner had done on that exam. There were 3 of these, for moving into phases 2, 3, and 4, with phase 5 being entered, instead, by choice or at the end of 8 weeks in phase 4. Experience taught that this regime consumed more Learner and staff time than seemed reasonable. Now the Guild has drastically abbreviated the evaluation: It lasts for 60 minutes total and consists of a live coding exercise.

The Guild’s position on placement, early in 2017, was that Learners would be prepared to find good jobs on their own, partly because of the unusually in-depth and holistic program offered by the Guild. That position has changed. Now the Guild has made it part of its mission to help Learners get employed when their time at the Guild will come to an end. This effort takes various forms. Its first manifestation has been regular opportunities to practice performing in a type of technical interview that has traditionally been prevalent in the screening of software-development candidates. Such interviews require a candidate to try to solve an algorithmic problem under time pressure. The problem is typically one that no programmer is likely to need to solve in real life, and this mismatch and the imposed urgency have led many observers to deem the entire interviewing system “broken”, but the Guild still offers simulations of such interviews to its Learners in all phases, and the staff indicates a belief that, broken or not, this interviewing system is still widely practiced in industry. Beyond interview preparation, the Guild is working on industry partnerships and has begun bringing visiting speakers in from industry. And, later this month, we are told that an outbound recruiter will join the staff.

Finally, until May the Guild was admitting monthly cohorts of new Learners. In May this changed, and it began admitting weekly cohorts. About September, however, it stopped admitting new Learners altogether. The explanation was that the Guild wanted to stabilize its new program first, and help existing Learners manage amidst the changes taking place under their feet. Then, it said, prospects would know what kind of program they were applying to, and the Guild would be able to treat them well. The enrollment suspension is still in effect, but the Guild is considering reopening itself to new enrollees early in 2018.

These are some of the main changes I have observed. The Learner population is diverse, and the changes have affected Learners variously. Some have left early, finding the program did not meet their needs. Others have prospered and already gotten good jobs while in later stages of their enrollment. Others, like me, have kibbitzed throughout the process, letting the Guild have our recommendations for program improvements, and otherwise focused on the job of becoming ever better software developers. The Guild has indeed listened to its Learners and has adopted some of the major proposals they have made. And it says explicitly that the changes have not ended.

 

Week 28 at an Unbootcamp

Saturday, November 25th, 2017

Is reputation management dead?

The coding bootcamp industry is under scrutiny and threat. And the hundreds of bootcamps around the world are competing to stay alive. Most of them charge money up front, so they want students who are willing and able to pay. A few of them charge money later, on the basis of success in the job market, so they want students who will achieve monetarily rewarding employment. In either case, they try to cultivate their reputations.

Learners Guild in Oakland, California, where my 28th week ended on 17 November, is one of the few that get paid only later and only insofar as learners achieve high earnings. The fact that one can attend the entire 40-week program (which is being slightly shortened to 36 weeks) without paying anything in advance, and can even get paid a stipend to defray living costs, helps it recruit Learners from disadvantaged and underrepresented categories, which is the core of the Guild’s social mission. But the Guild’s reputation also matters.

So, how does Learners Guild build its reputation?

  • It markets itself.
  • It graduates Learners with in-demand technical and social skills, who then get rewarding jobs in industry and participate in open-source software development, demonstrating the value of the training one can get at the Guild.
  • It cultivates alumni relations and industrial partnerships.
  • It offers (or at least is planning to offer) software development as a service, leveraging the skills of its staff and Learners.
  • It differentiates itself from coding bootcamps, framing itself as something essentially novel, based on apprenticeship, mentoring, and teamwork, not formal instruction.

As to this last point, has the “We’re not one of those bootcamps” assertion worked?

My father once told me, “You can’t decide whether you’re Jewish. If the world thinks you’re Jewish, you’re Jewish.” Analogously, the world thinks that Learners Guild is a coding bootcamp, despite its effort to be different.

You can see that in the inclusion of Learners Guild at websites that aggregate reviews of coding bootcamps. The reviews posted there have been harsh. Look at Course Report and Switchup. As of this writing, the Guild gets about 2 out of 5 points at both sites, on the basis of mostly scathing and anonymous reviews. It’s easy to imagine a prospective applicant looking at the Guild’s own marketing and this collection of reviews and deciding to believe the reviews.

But whom can one believe? Suspicion of the accuracy of promotional marketing is rivaled by suspicion of the honesty of customer reviews. Stories about reputation management in this world of review sites are rampant. Glowing fake reviews by friends and family. Fake diatribes by competitors. Reviews hidden when companies refuse to pay. What, then, accounts for the Guild’s nasty reputation among reviewers? I have a few (non-conspiratorial) hypotheses:

  • The Guild has underplayed the instability of its learning environment. Its product is a prototype, only about a year old, and has been drastically revised every few months as the Guild discovers what does and doesn’t work well. Some Learners have welcomed the reforms, but others have decided that they aren’t getting what they were promised.
  • The Guild has succeeded in its aim to recruit a remarkably diverse assortment of Learners, not only ethnographically but also emotionally, cognitively, and experientially. That success makes it difficult to design a program compatible with all the participants’ learning styles and needs.
  • The major changes in the Guild’s program impair the predictive value of reviews that are more than a few months old, but most of the posted reviews evaluate a program that is no longer in effect.
  • The Guild has not tried hard to break out of the coding-bootcamp model. If, as some claim, bootcamps simply cannot produce graduates with the deep and sophisticated knowledge that industry requires, that challenge affects the Guild, too. It may be even more serious there, since failing to become a professional developer is a worse (and more surprising) result if one has spent 40 weeks trying than if one has dedicated only about 12–15 weeks in a more typical bootcamp program.
  • Out of the roughly 150 persons who have been passing through the Guild’s program, fewer than 20 have chosen to post reviews, and most of those are current or former Learners who were severely disappointed. I estimate that about 20% of the total Learner population has seriously regretted joining the Guild, about 20% has found the Guild a rewardingly life-changing experience, and about 60% is arrayed across a range of responses, mixing specific satisfactions and disappointments.
  • The Guild is doing nothing to instigate Learners to post reviews. It does profile some happier Learners in its own marketing, but it is not appealing to such learners to spread the word on Course Report, Switchup, Yelp, or other sites.

If Learners Guild can keep experimenting until it finds a viable and clonable model, it will have done itself good by not trying to seed review sites with praise. It is forcing itself to focus on building a genuine and durable reputation by turning out successful graduates. And who knows, maybe the chaotic sequence of pilot projects that is the Guild’s reality will turn out to be great preparation for the dysfunctional organizations that most of us will work in.

 

Week 27 at an Unbootcamp

Sunday, November 19th, 2017

What should I do now?

The software-development curriculum at Learners Guild in Oakland is being revised again (the last major overhaul took place in June), this time with substantial involvement by Learners themselves. During my 27th week there (ending on 10 November), while the final revisions were being made by the staff, Learners continued to enjoy plenty of advice on how to progress toward eligibility for gainful employment, and access to expert coaching and presentations in support of further learning, but almost complete freedom to choose what aspects of software development to study. Most of my peers in “phase 4” spent their afternoons working in teams on projects to add features to the Guild’s own software, after devoting the mornings to practice solving programming problems under time pressure and explaining their solutions as would be required in a job interview.

I joined the majority in most of the morning exercises, but otherwise defined my own concentrations. I had already spent a few weeks contributing to improvements in the ESLint project, which provides the most popular style-management system for JavaScript programmers. When I say “popular”, I mean, for example, that programmers download it about 2.4 million times per week. I continued making such contributions during the week. But one of my recent contributions was still being evaluated, and I wanted to wait for the evaluation to be completed before I decided how to continue its work. So I decided to take a break from ESLint and pondered what else to work on in the meantime.

I decided to do something that would let me learn more about a near-universal problem faced by the inhabitants of the digital universe: search. I happened to own a collection of about 15,000 documents that (like any document repository) could use better search tools, so I was motivated to learn how to make website searching accurate, user-friendly, and powerful.

Despite its ubiquity on the web, search was only barely mentioned in the Guild’s curriculum. For example, in working on a Guild module, I had developed a search interface for movies, but it merely let the user enter a query and fed that query to IMDB to run whatever search IMDB chose to run. As I mentioned at the time, the results given by IMDB could be mystifying in their irrelevance. And, if IMDB couldn’t do better than that, there must be a demand for people who can improve search engines.

The search begins

I started by investigating tools for creating search engines. Before long I decided to figure out how to use Solr, an open-source project that the Apache Software Foundation has been developing for the last 11 years. It is written in Java, which I last studied or used a decade ago. So I intended to use Solr as a tool in developing a document-repository website, but not to contribute to the development of Solr itself. Nonetheless, as I began to study its documentation, I did find some inconsistent or ambiguous parts and contributed corrections to the project.

Solr is complicated. Consider that it can analyze HTML, XML, Microsoft Word, Microsoft Excel, PowerPoint, OpenOffice, PDF, RTF, plain-text, and other file types that it encounters in your collection. When I say “analyze”, I mean reduce what it finds to a set of attributes and values. For example, if your repository contains documents on treaties, you can tell it to find treaty names, subjects, parties, execution dates, and ratification dates, and Solr will try to do that, converting a heterogeneous collection of documents to a body of structured data. With those data you can, in principle, answer users’ questions about particular treaties or treaty statistics. How good a job does it do, though? That’s one of the questions I wanted to answer, but first I needed to figure out how to use it, so I could develop a site offering search with Solr. Once it worked at all, I would then evaluate it (getting some judgments from test users) and try to make it work better.

Studying Solr was frustrating. Although it is extensively documented, there are gaps that make it difficult to figure some basic things out. For example, if you want to use Solr to give users the contexts in which the terms they search for appear in files, how do you do that? I expected that use case to be covered prominently, but it wasn’t.

By week’s end, I was making progress, but had nothing to demonstrate yet. I was tempted to give up, but reminded myself that this difficulty would make competence in Solr even more valuable in the market than if it were easy to learn. When debugging problems became hard to tolerate, I got an hour of help from one of the phase-4 professional developers. This showed me that there is no magic bullet. The pro did detective work as I was doing it, only faster and with more tricks in his inventory. Solr, ESLint, and similar mature projects are far too complex to be fully understood. Debugging requires not just reading the documentation. It also requires poking at the tool and seeing how it behaves, until one finds a solution, despite the fact that one doesn’t understand why the solution is a solution. Sometimes it is wise to settle for that much.

 

Week 26 at an Unbootcamp

Friday, November 10th, 2017

More interviewing

During the week ending on 3 November, my 26th week as a Learner at Learners Guild in Oakland, the emphasis on preparation for employment as a software developer continued to grow more intense. By that I don’t mean learning to develop software of a kind that is in heavy demand; I mean learning how to break into the industry.

Of course, these two things are associated: You can get hired as a software developer more easily if you are good at at doing something people want to pay for than if you aren’t.

But the prevailing wisdom at the Guild is that being good and relevant is not enough. In other words, the staff and Learners agree with the often-made claim that the hiring process in the software industry is dysfunctional. By this account, success at being hired depends also on friendships, self-confidence, and interviewing skill. And interviewing skill, even in technical interviews, is a skill apart from programming skill.

So the professional developers who guide phase 4, the final period of our tenure as Learners at the Guild, introduced a new exercise during the week: mock technical whiteboarding interviews. We are randomly split into groups of 3. In each group, one Learner plays interviewer, one plays interviewee, and one plays observer. The observer’s job is to advise both of the others about the strengths and weaknesses of their performances. In a whiteboarding interview, the job candidate gets a problem and has to write a program to solve it on a whiteboard, explaining the solution to the interviewer and answering any questions, such as “Now that you have a working solution, can you think of ways to make it more efficient?”

A glimpse of the future

The staff during the week also described in rough outline some ideas for revisions in the Guild’s curriculum and business model, based in part on proposals recently received from Learners. They involve new ways to make expertise available to Learners, new methods for organizing the learning of software fundamentals, new principles underlying the contractual relationships between the Guild and its Learners, new partnerships between the Guild and industry, and a new Guild-sponsored opportunity for Learners to join a team of software developers providing services commercially. My sense is that the Guild wants to try, accept or reject, and refine these ideas before it again begins admitting new Learners.

 

Week 25 at an Unbootcamp

Wednesday, November 1st, 2017

School-to-work pipeline

Learners Guild in Oakland has prided itself in turning out software developers so skilled that they can get themselves happily employed without any placement services from the Guild. This is in contrast with various coding bootcamps, which all-but-guarantee jobs or internships to their graduates. It also shows impressive confidence in the program, since the Guild’s own investors are financing Learners’ education and the return on their investment depends on ex-Learners earning good incomes.

That notion is no longer an article of faith. The Guild is beefing up its efforts to facilitate post-Guild employment. As I finished my 25th week, out of 40, at the Guild on 27 October, concern about rapid employability was increasingly in the air:

  • Learners have increasingly chosen to immerse themselves in high-demand technologies, including React, Redux, React native, Ethereum, and Deeplearn.
  • They have branched out from the Guild’s primary programming language, JavaScript, to add other often-demanded languages, including Python, Java, C++, and Objective C, to their skill sets.
  • Algorithm puzzles on HackerRank are now a daily exercise. For example, in a few minutes, write a program that determines whether 1 letter can be removed from a collection of letters and the result will be a collection in which each letter that is present at all occurs the name number of times. Then figure out whether you could have written the same program differently so it would run faster. Such problems reportedly occur during technical interviews for programming jobs.
  • Learners have organized a group that is creating a website showcasing the portfolios of advanced Guild Learners available to be hired.
  • Another group of Learners is creating a small software consulting business within the Guild, in which they can get real-world project experience.
  • Learners and coaches are offering practice interviews to each other, and some are making use of commercial practice-interview services. A manager from Karat came to give a talk this week on how technical interviewing really works.
  • Learners about every week are going to meetings where they can make industry contacts.

Although I don’t feel anxious about unemployability, my own current focus, contributing improvements to the ESLint project, arguably fits the pattern. According to many (but not all) commentators, competent employers hiring software developers look at the open-source contribution records of candidates and treat them as significant evidence of quality.

 

Week 24 at an Unbootcamp

Sunday, October 22nd, 2017

Whither the Guild?

Learners Guild in Oakland continued, during my just-ended 24th week there, to reassess how it is and will be organized. After giving its Learners a couple of weeks to put proposals together, executives and Learners gathered in mid-week to review and discuss those proposals. They included novelties such as:

  • a turn from well-entrenched web-development technologies to bleeding-edge ones like blockchain development
  • commercial sponsorship of Learners with individualized studies aimed at placement with the sponsors
  • an emphasis on the retraining of discharged United States military personnel for civilian employment in software development with support from government grants
  • the redefinition of the Guild from an educational establishment to a software-development firm and of its Learners to apprentices

The Guild has already made 2 announcements in response to Learner input:

  • Current Learners will not be required to advance from phases 1, 2, and 3 to the next phase within a maximum of 8 weeks. As a result, some Learners may reach the ends of their Learnerships without having reached the final phase.
  • Phases 4 and 5 are being combined into one phase. This creates a phase involving an array of real-world-based activities, including creating and improving applications for regular use and getting ready to find post-Guild employment.

We don’t yet know what more fundamental decisions the Guild will make about the submitted ideas, but it seems clear to me that the people in charge have paid close and respectful attention to them. My guess is that something significantly innovative will emerge from the process.

Meanwhile …

Life goes on in the Guild as it is. Although I spent some time writing and presenting one of the above-mentioned proposals (the apprenticeship one), most of my life during week 24 was focused on continuing to contribute code and documentation to the ESLint project, which I described last week. By now I have submitted 12 “pull requests” (formal submissions of changes for inclusion in the running software), and 9 of them have already been “approved” (endorsed by decision makers) and “merged” (incorporated into the active software).

At week’s end I was in the midst of work on one of ESLint’s 208 open “issues” (it has 5,321 closed issues). The issue I chose was a request to make ESLint emulate one of the rules of JSCS, another linter. The people running JSCS have decided to fold up and ask their users to use ESLint instead. So there is pressure on ESLint to do at least everything that JSCS can do. One of the JSCS rules that ESLint doesn’t yet emulate is named “disallowObjectKeysOnNewLine”. Let me explain this.

JavaScript programs package information together into “objects”. Here’s an example:

const congress = {
  creator: 'constitution',
  branch: 'legislative',
  houses: {
    senate: {
      size: 100,
      yearsInTerm: 6
    },
    houseOfRepresentatives: {
      size: 435,
      yearsInTerm: 2
    }
  }
}

This code defines congress as a variable whose value is an object. That object has 3 “properties”. Each property has a “key” (or “name”) and a value. For example, the first-named property has the key creator and the value 'constitution'.

You can see that other objects are embedded in this object. The houses property has an object as its value, and that object has 2 properties, each of which has an object as its value.

After defining such a structure, we can tell a machine to look up information in it, by using expressions such as congress.houses.senate.yearsInTerm, yielding 6.

Machines don’t care how an object like this is laid out, as long as it has the braces, commas, colons, and quotation marks where required. Thus, a machine would be just as happy with it all on a single line:

const congress={creator:'constitution',branch:'legislative',houses:{senate:{size:100,yearsInTerm:6},houseOfRepresentatives:{size:435,yearsInTerm:2}}}

But we write code for a mixed audience: machines and people. We want it to satisfy both. That’s why we use linters. They let us impose requirements on our writing so that it is syntactically correct and also so that humans will enjoy it.

The JSCS rule mentioned above, “disallowObjectKeysOnNewLine”, prohibits the first format shown above, allowing only the second format (although spaces may be inserted). JSCS also has another rule, “requireObjectKeysOnNewLine”, that does the opposite. ESLint already has a rule like the latter, but has no rule like the former.

Who, you might ask, would ever want the “disallow” rule? Who would want human-impenetrable code? Why should anybody spend time emulating a noxious rule?

Actually, there could be a good reason for using the “disallow” rule. There is a shorthand syntax for representing property keys and values that works in some situations, and if all of your code uses that syntax then you could have objects looking like this:

const address = {number, street, apt, city, state, zip};

If that’s how the code in some application is designed, you might reasonably decide to require yourself to keep all the properties of each object together on the same line.

Anyway, the person who created this issue proposed that we modify the existing ESLint rule so it can not only require properties to be on separate lines, but also prohibit them from being so, thus emulating both JSCS rules with a single ESLint rule.

Easier said than done. In working on this issue, I discovered that the existing ESLint rule does not completely emulate the JSCS rule requiring line separation. For example, the JSCS rule says that

const member = {
  firstname,
  lastname,
  age,
  email
}

is compliant, but

const member = {
  firstname
  , lastname
  , age
  , email
}

is not. You may think that nobody would put commas before items in a list, but some programmers do that, and, as I said, machines don’t care.

The ESLint rule, however, deems both of these formats compliant. At present, ESLint’s documentation says that its rule is compatible with the JSCS rule, so I am addressing a couple of problems:

  1. Correcting the documentation to describe the discrepancies.
  2. Doing something about the rule to permit users to emulate the JSCS rule if they wish to.

I am also revising the documentation to add missing information, adding tests to check for possible faults that the existing tests don’t cover, and pondering whether it makes sense to take a prohibitive rule and make it also mandatory, instead of creating a new rule.

Luckily, we contributors have quick access to veteran ESLint authorities for judgments on whether and how to resolve such problems, and interested users can chime in with their opinions.

My most enlightening lesson from this activity is how low the barrier to entry is. The whole ESLint software and documentation package is about 170 million characters in size and contains about 20,000 files. That includes others’ packages that it incorporates into itself. How could a JavaScript novice improve such a package within a few days of deciding to help out? Learners Guild tells us that the main skill we are learning is “figuring things out”. That includes figuring out what we don’t need to figure out. What I have needed to figure out for this work is an infinitesimal fraction of ESLint. That fraction keeps growing, but only gradually. The system is modular enough, and the code is intelligible enough, to let learning and contributing progress hand in hand. A good thing. If one needed to spend months or years learning how it all works before starting to participate, I don’t know anybody who would.

Week 23 at an Unbootcamp

Sunday, October 15th, 2017

Best practices

As I noted last weekLearners Guild in Oakland works to instill in its Learners a variety of virtues, not just the ability to write code that computes correctly. The best practices include:

  • Stylistically consistent code (with respect to indentation, punctuation, capitalization, etc.)
  • Well-modularized code (each piece doing one thing)
  • Self-explanatory names of variables
  • Test-driven development (writing thorough tests before coding)
  • Parsimony (putting any code that is used multiple times into a named function rather than repeating the code)
  • Kind, helpful, and respectful conduct toward teammates

An important practice that supports the first of these is linting. You might think of this as an automatic process that reads all of your code and screams at you if you have failed to comply with the counterpart of the Chicago Manual of Style or the Blue Book. At Learners Guild, the linter most commonly recommended is named ESLint. Unlike some linters, it has only one opinion: You should be consistent. It doesn’t care which rules you obey, as long as you obey them all the time. You decide to turn rules on and off, and, if you turn them on, you can make them either fail your code or merely warn you. In this respect, linting with ESLint is distinct from using published style manuals, since manuals usually tell you which rules to obey. ESLint is basically a write-your-own-style-manual tool, which then enforces your rules for you.

Reaching out

During my just-ended week 23 at the Guild, my relationship with ESLint changed. Here’s the story.

I’m in phase 4, where Learners have stopped doing exercises and are actually helping build, improve, and repair real open-source software. I began, like everybody in phase-4, doing this with the software that manages the Guild’s own curriculum and monitors the Learners’ progress through it. I added missing functionality and repaired bugs that I found.

By mid-week I had reached a reasonable turning point. I had submitted 80 different changes to the Guild’s software and was waiting for them to be approved and incorporated into the running code (or criticized for flaws requiring correction). However, phase 4 was suffering from a temporary shortage of leadership, causing the work done by the Learners to pile up and leaving some of us without obvious ways to make more contributions.

This personnel imbalance was one manifestation of the flux that the Guild is now in, as it takes stock and embarks on an effort at cooperative (i.e. Learner–staff) redesign of the Guild itself. In response, some Learner time is being spent making proposals for Guild reorganization. Other than that, Learners are exercising plenty of de facto discretion in deciding how to progress as members of this learning community. Several Learners are busy learning (and teaching each other) technologies and frameworks that have not (yet) made it into the curriculum, such as blockchain development. I decided this week to shift my contributions from the Guild’s software to external open-source projects—something that is in the phase-4 description but was not currently being practiced.

Having made this decision in principle, I proceeded to survey the thousands of open-source projects that can use contributions from JavaScript developers. After a couple of days of research, I narrowed my list of candidates to 6 projects: Etherpad Lite, pdf.js, Sandstorm, Sequelize, Material Components for the Web, and ESLint. I ultimately chose ESLint. Thus, I decided to stop being merely a user of ESLint, and start also being one of its producers. (“Making my own dog food”.)

When you decide to contribute to such a project, you first follow the instructions for contributors. They tell you how to install a copy of the software on your own computer. That’s where you’ll do all your coding and testing, before you are ready to submit proposed changes.

I followed the instructions and got to the point of running the existing tests, to ensure that the software on my machine would behave as expected. I entered the command, npm test. About 2 minutes later, I got the results: 17,644 tests passing, 1 test failing.

I couldn’t start working on the code until the count of failing tests became 0. A single failing test is unacceptable. But hey, what an opportunity! Maybe I could figure out what went wrong with that test, and, if it was a problem with the test, I could correct it, thereby making my first contribution to ESLint. That is exactly what I did. The culprit was, indeed, a flaw in the test. The test made an assumption that I wouldn’t have a certain file in a certain directory—but I did. So I proposed a sequence of changes to deal with this problem, starting with instructions and warnings to contributors and more accurate error messages, and ending with a revised test that would not fail under the same condition.

When I began submitting proposals to change the documentation and code, project personnel began responding within 15 minutes. Proposals that were ready for adoption were merged into the running code within hours, or by the next day. Proposals needing revision elicited clearly explained change requests. And accepted contributions got expressions of gratitude.

What ESLint has, and Learners Guild (like the vast majority of open-source projects) is only beginning to approach, is a rock-solid system for managing volunteer labor. The instructions are exhaustive. The battery of tests is enormous. The response time to contributions is lightning-fast. And the decision makers are courteous, clear, competent, and thankful. A corollary benefit is personal validation: If you get contributions accepted and incorporated into ESLint, then you know (and any JavaScript developer knows) that you must be doing something right.

We Learners are now being asked to tell the Guild how to make itself better. One piece of advice I’m giving is: Make contributing to external projects a fundamental element of the curriculum, and help us learn to do it well.