Archive for November, 2017

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.