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.