Archive for the ‘1. Work’ Category

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.


Week 22 at an Unbootcamp

Saturday, October 14th, 2017

Making it work

For me, week 22 at Learners Guild in Oakland was the second week in phase 4. In that phase we aspiring software developers make use of our theoretical learning and programming exercises to work on real open-source applications that have real users.

In mid-week, I finally finished getting myself set up to work on the applications that Learners Guild itself uses to manage the learning process. Using those applications, Learners choose the modules they wish to study, check off the skills that they are acquiring, get paired up to work on joint projects, look up technical terminology, identify their fellow Learners and the projects they have worked on, and look up Guild policies and recommendations.

With that preparation liquidated, I started work on an as-yet unclaimed task: writing tests for a few database functions. The idea here is that there should be a batch of tests that can be performed on the software to verify that it is working as expected, and, before any change in the software is incorporated into the active version, those tests should all be run. If any of them fails, the change should not be activated.

My job was to write a few such tests for functions that keep track of the skills that Learners have acquired. In principle, those tests should have already existed. In fact, in line with the practice of test-driven development, embraced by the Guild, the tests should have been written before any code was written. They would all fail, of course. Once the coding began, one by one the tests would begin to pass. Eventually they would all pass. But this discipline had not been observed when the Guild’s staff hastily threw together the software for a new curriculum a year ago, nor when it revised that curriculum in June. Better late than never, phase-4 Learners were now creating tests retroactively.

In the course of developing tests for the management of Learners’ lists of skills, I discovered that this function had stopped working. Learners who marked skills found that those skills were no longer marked when they returned later to the page listing all the skills. So I set about figuring out why. The software is so complex that I didn’t feel at liberty to learn how it works in elegant detail before diagnosing this bug. It was a process of poking the software to see how it would respond and investigating any hypotheses that came to mind. Within a few hours I had discovered the reason for the bug: Somebody had changed the name of a column in the table of Learners’ skills, but neglected to make the same change in the function that recorded changes in those skills. Every attempt to record a change with that function (silently) failed because of the misnamed column. So I corrected that defect in my own local copy of the application and verified that the application was now recording skill-repertoire changes. That done, I submitted the correction for review and approval and then proceeded to develop the tests. Had my new tests existed in the beginning, that bug would have been caught as soon as the column was renamed.

The Guild knows that a rigorous testing discipline is a “best practice” in software development, but, like many small startup firms and many individuals, it doesn’t always comply with the principles that it espouses. So, are we learning from its example to be casual about testing? Or are we learning to do rigorous testing? In my own case, at least, I perceive lapses in the Guild’s own software discipline as negative examples to be avoided. They seem to be hardening my resolve to do things right. “Do what I say, not what I do.”


Week 21 at an Unbootcamp

Friday, September 29th, 2017

Soft landing

During my first 20 weeks at Learners Guild in Oakland, studying to be a state-of-the-art software developer, more advanced Learners told about the incomparable difficulty they had experienced in transitioning from practice programming to for-real programming. For the first half to ⅔ of their time in this 40-week training program, they had learned by writing make-believe programs. For example, they built websites where (imaginary) users could order (imaginary) groceries from an (imaginary) store, choosing from an (unrealistically tiny) list of products. But then they suddenly got promoted and joined the team of Learners debugging, maintaining, and improving software in actual current use. It might be the Guild’s own software, used by its administrators and Learners. Or it might be other open-source software with users around the world. In either case, advanced Learners reported that the increase in software complexity accompanying this transition was traumatic, exacerbating or creating whatever amount of imposter syndrome they already had or didn’t have. No amount of prior training, they suggested, could have prepared them for the shock.

Well, I have just survived my first week in that phase, which the Guild now calls phase 4. If blood and guts sell news, the week ending today (29 September) was nowhere near as newsworthy as I had been warned to expect. Two of us Learners started phase 4 this week, and we both seemed to take it in stride.

Yes, indeed, there was a lot of new information and technology for us to begin getting familiar with. During my very first day in phase 4, I started learning the following concepts and techniques for the first time:

Why, then, was this not an overwhelming cognitive load?

I’d say the main reason is the Guild’s contagiously relaxed attitude about getting up to speed. During the week-end review of our work by the dozen of us in phase 4, my fellow cohort member said she was concerned that it had taken her 2 whole days to get her new software installed and running so she could start doing real work. When my turn came, I said it had taken me the entire week to do that, and this didn’t bother me at all. (In fact, I haven’t finished it yet.) This 3-to-1 ratio was due to our radically distinct strategies. She had in-person mentoring from the most advanced Learner in phase 4—somebody who derives obvious delight from coaching and brings to bear a phenomenal amount of know-how. By contrast, I eschewed such offers of help except in a few extreme cases, and instead pursued my own favored strategy: following the step-by-step written instructions and, whenever they were not correct and clear, editing them so that future entrants into phase 4 would not require much—or any—handholding.

What is notable about this is that neither our staff supervisor nor any of my phase-4 peers had any objection to either of these divergent approaches. She got started sooner with the work, but I helped make future onboarding more efficient. These styles were both treated as within the normal range. The installation instructions themselves plead with their readers to fix anything in them found to be deficient. The staff reiterated that. So I had no doubt that my investment of time in this activity was welcome. No pressure, no shaming, no hazing.

Let me also mention that figuring out what the instructions should say taught me a lot.

Making the system work—together

Learners Guild is known for its demographic diversity, but this incident illustrates its acceptance of cognitive and stylistic diversity, too. Making itself comfortable for those with diverse learning styles is an easy goal to proclaim, but not to achieve. The realization of this ambition is a work in progress at the Guild. Some Learners have made it clear that the curriculum and the learning process are not yet effective for them. It remains to be seen how wide a range of learning styles and needs the Guild can accommodate.

In the effort to make the learning environment work for a diverse clientele, the Guild has said that it wants Learners themselves to be co-designers. The intent appears to be genuine. This week the Guild began putting into place its plan to make the Learners true creative partners. The Guild’s CEO introduced Learners to the financial model powering the Guild as a business, financial results during its first year, and what-if projections with various assumptions. Learners will be grouping to make proposals for the Guild of the future. Because they will have the financial details, they will have the ability—and the moral obligation, one could argue—to justify the practical feasibility of their proposals.

Can students design their school? They’re about to try.


Week 20 at an Unbootcamp

Saturday, September 23rd, 2017

Getting real

Learners Guild in Oakland offers a 40-week program of project-based training in software development, centered around web applications written in JavaScript.

The training functions are distributed, with more advanced Learners helping less-advanced ones, as in the proverbial one-room schoolhouse. There are also ex-Learners serving on the staff as coaches, and professional programmers holding office hours, checking Learners’ code in group sessions, and giving lectures. Most of the time, Learners are figuring out how to build applications, either solo or with a partner, by absorbing documentation, tutorials, and other resources, then writing, testing, and revising code until it works.

I have just completed my 20th week there, and during the week I underwent an exam and a technical interview to establish my readiness to progress from “phase 3” to “phase 4”. The exam took me the 2.5 days allotted, and the interview was tough, resulting in a half-page of recommendations on further study to solidify my fragile competence in certain important pieces of web technology. But the evaluator decided that on the whole I had what it took to proceed to phase 4.

Phase 4 will involve leaving make-believe projects behind, and working on real open-source software, namely the software that powers the instructional system of Learners Guild itself. That software, as is always true, needs to have bugs removed and infelicities remedied. But Learners Guild is reinventing its curriculum, not only in content but also in structure, so the demands on phase-4 Learners include making improvements, often previously unanticipated ones, in the existing code, without introducing new faults into it.

Word on the street is that it is a shock to find oneself in phase 4, because the huge body of code with its many depended-on software libraries is far more difficult to make sense of than the self-contained practice applications we have been building in the earlier phases. I’ll be finding out shortly whether my reaction is the same.

Meanwhile, on Saturday I attended an orientation to another opportunity to contribute to open-source software, the Open Oakland brigade of Code for America. I began to learn which of its projects are still alive and which of those might be able to use my help. If, however, the immersion into phase 4 is as traumatic as rumored, my temptation to engage in such extracurricular volunteering may be postponed.


Week 14 at an Unbootcamp

Saturday, September 23rd, 2017

Week of reckoning

My 14th week studying web software engineering at Learners Guild was a week of reckoning—in a figurative sense and in a literal sense.

Figuratively …

Under the Guild’s new learning model, Learners undergo a progress assessment at least every 8 weeks. The first assessment, for all of us, was during my 7th week, starting on 19 June. It placed me into “phase 2”, out of 5 phases. Consequently, I was required to undergo another assessment no later than my 15th week, but getting assessed earlier was recommended, since by doing so a Learner could get re-assessed in the 8th week in case the initial assessment was unsuccessful. I chose to undergo my assessment (for admission into phase 3) during the week ending on 11 August, my 7th week in phase 2 and 14th week over-all.

So, it was a week that could send me on to phase 3 or keep me in phase 2 for another try a week later. The take-home-examination portion ran from Monday morning until Wednesday at noon, and satisfying all the requirements took me all of that. The interview portion lasted an hour, and mine was late Wednesday afternoon. Well-conducted, a technical interview of that length was enough to show that I had done my own work, I knew what I had done and why, and I could identify remaining gaps in my related knowledge. Within minutes after the interview ended, I got an official email congratulating me on my admission into phase 3.

Literally …

That left the rest of the week to my discretion, and I decided to keep working on phase-2 study that I had interrupted for the assessment. I had been in the middle of an exercise called “Mac Calculator Clone”, within a module named “JavaScript in the Browser”. The topic was making an application that your web browser can run all by itself.

Perhaps this exercise, like most, should have taken me a day to complete, and I should have moved on to the next module. But no. More than all the previous exercises, this one kindled my imagination and ambition. Why? Because the instructions told me to “clone” the Macintosh OS X “Calculator” application. As I began figuring out how to do that, I gradually changed my question to whether to do it and, if not, what to do instead.

This raises two obvious issues, so let’s deal with them.

  • First, do we, lowly Learners, have the authority to modify the specifications?
  • Second, why not clone the Mac calculator?

As to the first question, yes, we do. At Learners Guild, we learn to code, but we also learn to think. And to feel. And to exercise agency. In fact, we have workshops aimed at helping us be both more powerful and more responsible in the social situations programmers exist in. So, if we want to depart from the specs and we can justify doing so, nobody objects.

Moreover, we have a standing invitation to propose changes in the specs themselves. I have made dozens of such proposals, and the Guild has adopted almost all of them, sometimes on the same day. We are improving our own curriculum as we work through it.

Still, why not clone the Mac calculator?

I have often used the Mac calculator, but as a user I merely used it. As a cloner, I had to scrutinize it. The specs told us to make our calculator follow the same rules, so I needed to figure out what those rules are. Easy? Not for me.


Mac Calculator

If you start fresh with this Mac calculator and enter 6 0 ÷ 3 0 % 5 0 =, you get 1.2.

Entering 6 0 + 3 0 % 5 0 = gets you 110.

Entering +/- 8 = produces 8.

The result of 6 – = 9 = is 3.

Do you understand why? With enough reasoning, one may be able to infer the rules (for example, in the first two cases, the 3 0 % part is simply ignored). But most of us want a calculator, not a mystery. It became obvious that these rules are not my rules of arithmetic, and I doubt they are intuitive for anybody else. So I lost motivation to reverse-engineer the product.

Here is a list of some deficiencies:

  1. Some rules are unintuitive.
  2. As pointed out by Stephan Weber, the order of operations is not sequential: × and ÷ take precedence over + and . If you want 4 – 2 x 5 to produce 10, you can’t simply enter 4 – 2 x 5 =, because that will give you –6 instead. You must enter 4 – 2 = x 5 = to get 10. (For some users, this is a virtue. Tastes differ. Apple itself is inconsistent: While its calculator application gives precedence to × and ÷, its calculator widget on its Dashboard application does not.)
  3. The initial result is 0, although the user has not entered anything.
  4. When a term is entered, the previous one disappears, although it is still essential.
  5. Buttons that cannot be used don’t change their appearance and continue to flash when pressed.
  6. The 0 button is double-wide, wasting a space that another button could occupy.
  7. It is impossible to divide by the result, because there is no reciprocal button.
  8. The portrait layout forces digits to be shrunk earlier than a landscape layout would.

A better-than-Mac calculator

During the rest of the week, then, I worked on making a calculator that would be better than the Mac’s. Like the exercise specifications, my calculator relates only to the Mac calculator’s “Basic View”. Improving on the “Scientific” and “Programmer” views and on other features, including converters for weights, measures, and currencies, would be a much larger project.

Better-than-Mac Calculator

Better-than-Mac Calculator

As this picture shows, my calculator displays the entire statement that will be calculated, so you don’t need to remember what you entered earlier. Here the decimal-point button is dimmed, because after you have included one in your current number you can’t enter another decimal point. The reciprocal button (¹/) lets you divide by a result. The rounded-equal button () lets you round an existing result, one decimal digit at a time, or perform a calculation with rounding. The operations are simply sequential. Finally, I would argue that this calculator does more benign things with extremes than the Mac version. If you divide 5 by 0 on the Mac, you get Not a number. On my calculator, you get Infinity, and you can then take its reciprocal, add 10, and, properly, get 10, since 1 divided by infinity is 0.

But you don’t need to take my word for it, or view only a static picture. Try it out yourself, and let me know what still should be improved, or report any bugs you may find. Feel free to comment below. Or, if you are comfortable with git, you may post an issue on Github or make your own improvements.

The Learners Guild curriculum reminds us every day of how little we know yet. Still, after 14 weeks of JavaScript study, a solo trainee can claim, in at least some respects, to have improved on the work of armies of programmers and designers in a near-trillion-dollar company. Pure chutzpah, perhaps. You judge.

(Originally published 20 August 2017; revised.)

Week 19 at an Unbootcamp

Sunday, September 17th, 2017

Come let us reinvent together

The new curriculum at Learners Guild in Oakland, an alternative to the traditional coding bootcamp, has elicited much debate among the Learners, and the Guild has responded by slowing its adoption so that Learners have enough time and information to intervene in the adoption (or modification) process.

On 15 September, as my 19th week there ended, the Guild set up new communication channels to help organize Learner engagement in what appears to be the ongoing redesign of our institution. Learners were informed that efforts are under way to disclose to Learners more of the Guild’s business information—it’s a one-year-old B corporation, with a profitmaking purpose and a social mission—so Learner participation can be based on realistic estimates of constraints.

Learners’ recommendations on the principles of their engagement have been wildly diverse, ranging from electoral representation with mediation of nonconsensual issues to subsidiarity. One might colloquially simplify the endpoints of this range as “Gimme a vote” and “Gimme something to do”.

Extensive Learner participation in the gradual redesign of the Guild seems to be advocated by almost all parties, in principle, but it does face obstacles. Learners’ job 1 is to learn software development, and the Guild reminds them of this every few weeks by subjecting each Learner to a 2.5-day exam and a technical interview for progress assessment. Whether insufficient progress will bring a Learner’s membership to an end remains to be decided as the redesign process continues. But assessment anxiety is in the air. In fact, few Learners regularly try to influence the process; most keep their heads down and code away.

Transition time again

Speaking of periodic assessments, mine is now due. I have been in Phase 3 for 5 weeks, and at week’s end I received the Guild’s routine exhortation to get myself evaluated during the following week. I responded compliantly, so on Monday morning my exam will begin, and by the end of the week I’ll know whether I’m considered to be proficient enough to move into Phase 4. In that phase, Learners work on real software that is in use by real people.

Meanwhile, the week’s project required my teammate and me to test a web application that others had developed. We spent most of the week trying to figure out whether some software libraries, with names like Phantom and Zombie, which allegedly make such testing easy, really do so, or instead make it impossible. Vaporware and miserably documented (but still popular!) software libraries are plentiful, so one must adopt defensively. I obviously have yet to acquire the skill of detecting such libraries quickly. This skill, it seems, is of extraordinary value to developers who are responsible for choosing their own tools. Maybe I’ll suggest a training module on that very topic for inclusion in the Guild’s curriculum. But, realistically, the way to get something into the curriculum is to create it, not just suggest it, and how can I create it if I myself need it? If you have the answer, please comment below.


Week 18 at an Unbootcamp

Sunday, September 10th, 2017

Starting all over again—and again

Week 18 in my makeover as a state-of-the-art web software developer has just ended. The projected duration of that transition is 40 weeks, the standard term of a Learner at Learners Guild in Oakland, so I’m nearing the halfway point. On exit, the expected status of a graduate is “junior software developer”.

On Tuesday morning (since Monday was Labor Day) I voted for a module titled “Debugging Snapshot”, and the Algorithm assigned me to it. My job was not to create anything new, but instead to inspect a web application written (and deliberately broken) by somebody else, figure out why it didn’t work, and repair it. The module could use some calibration, because I finished correcting the bugs by the end of the first day.

This despite the fact that on Tuesday afternoon I hosted a talk by another visiting brother of mine, this one a venture capital investor in energy-efficiency and clean-tech industries. About 15 Learners engaged him in a lively Q&A session about combining dissimilar careers, startups as places to work, doing good while making money, and other topics. (My brother, ever the bearer of gifts, treated the attendees to chocolate and taramisu 75th-birthday cakes, too.)

Quick completion of the debugging module allowed me to resume work on the “Pizza Restaurant” module that I had begun a week earlier and was, as reported earlier, not close to finished. By the end of this week, I had made good progress, and the end was apparently in sight.

By tomorrow I may eat those words. The week’s work illustrates that my makeover (and I don’t seem to be alone in this respect) consists largely of repeated makeovers.

As I mentioned last week, I have revised the design of this application’s database many times. The two weeks have witnessed design revisions about daily. As one example, on Friday the professional in charge of my group (Phase 3) advised us never to design a system in which each person has a role. Does your model of a school give each person a role such as teacher, student, janitor, or parent? Bad! That design is destined to break as soon as anybody needs to have 2 or more simultaneous roles, and there will be many points in the code that must be revised to accommodate the needed change. Shame on me. Knowing this, I had nevertheless provided for sole roles in my design. I duly revised this, creating a table of role assignments so that anybody could have any number of roles at once.

Another kind of makeover is “refactoring”. I got all the pieces of my application to work together, and then, instead of basking in self-congratulation, I looked more critically at the code. Let’s face it: The code reeked of repetition. The parallel routines could, obviously, be combined and called on from multiple places. So, a few times, that’s what I did. The last of these refactorings consolidated 16 functions into 2.

This habit of finding my own work to need fundamental reorganization and compaction seems not peculiar to software development. In academic and other writing, what I have been proud of one evening has usually become an embarrassment the next day, and eventually could be shrunk by about 50% with a boost to its lucidity. While getting anybody else ever to read my writing has always been a struggle, being a student again confers a right to critical code reviews by professionals, and an expectation that peers, too, will comment on one another’s work. We Learners are awash in opportunities to discover and rectify our mediocrities. I hope to enjoy 22 more weeks of such bliss before my graduation into juniority.


Week 17 at an Unbootcamp

Friday, September 8th, 2017

Beating pizzerias into helpshares

My 17th week of study at Learners Guild ended on 1 September. On Monday I voted, as one does in Phase 3, for my 2 most preferred modules to work on for the week. As has almost always been true, the Algorithm gave me my first choice. In this case it didn’t assign anybody else to work with me, so it was a solo project. I did confer often, though, with another Learner who had been assigned to the same module.

The module was titled “Pizza Restaurant: Relational DB With CRUD API”. Let’s start by unpacking that for the general reader. A relational database (DB) is a collection of data organized into interrelated tables. For example, a database for a pizza restaurant could contain tables of ingredients, pizzas, customers, employees, suppliers, etc., and other tables combining these (e.g., a table recording which pizzas contain which ingredients). An application programming interface (API) is a service that provides to programs the ability to do things with such a database. And a CRUD API is an API that lets programs create (C), read (R), update (U), and delete (D) data.

The module told the Learner to create a relational database and a CRUD API for an imaginary pizza restaurant. The instructional value of the module did not depend, however, on us modeling that particular kind of business. Therefore, the module’s author had wisely invited Learners to feel free to model anything else instead. As you might imagine, I took the author up on this offer. I decided to model not a business at all, but rather a community of learners who help each other acquire skills. I tentatively named the project “helpshare”.

The most important task was to define a model of this institution. What are the entities in it? How are they related? What data are gathered and stored? What entities have what powers to CRUD the data? This was not a one-time decision for me. I kept revising my design all week long. I aimed for some reasonable combination of simplicity and realism, and that was elusive. In addition, I needed to create a database reflecting the model and write the programs that would control the interaction of other programs with the database.

The project was far from “complete” by week’s end. In the new Guild, no longer characterized by weekly deadlines, that was no problem. So I kept working on it over the (long) weekend, and beyond. I hope to let you try it out and give me comments, once it works.

On Friday I hosted a visitor at the Guild, namely one of my brothers, who began programming computers 55 years ago and is still making his living doing so, currently in the domain of pharmaco-vigilance. He gave an informal talk to a dozen Learners and fielded questions about how software development has changed over time, the skills that make programmers competitive, and other topics. We Learners are the main impresarios of visiting speakers at the Guild. Getting a time slot in the conference room is not always easy, but group meetings take place in various sofa alcoves, too.

Speaking of alcoves, the Guild offers various physical environments for Learners to choose among. There are low and high 2-person tables for sitting and standing, couches, and even mattress alcoves for horizontal work and nap-taking. There’s a stability ball in use, and I’ve recently been trying out an elliptical exercise machine while standing and sitting at desks.