Week 14 at an Unbootcamp

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.

calc

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

Leave a Reply